Software Engineering Radio - the podcast for professional software developers

In this Episode we discuss software architecture evaluation with Dragos Manolescu, an architect at Microsoft's patterns & practices group. We start off the discussion by trying to define what software architecture evaluation is and when and you want to evaluate an architecture in the system's lifecycle. We then make sure evaluators set the expectations for the evaluation process right - it is important to understand that architecture evaluation is typically not primarily a review of the technology decisions made for the architecture. We then discuss the kinds of notations that are useful for describing architectures, and which of these are especially helpful for the evaluator. Next we look at the core of the architecture evaluation task, namely, the integration of the various stakeholders and their views. We also discuss real reviews from reviews that are staged "for show" only. Next in the discussion is a brief look at the tools you can use for architecture evaluation, as well as a closer look at the various methods for achitecture evalualtion proposed by the Software Engineering Institute (SEI). We conclude the discussion by outlining how architecture evaluation fits into an agile development process. ... and finally, we briefly plug the PLOPD5 book, on which Dragos, Markus and James Noble have been working recently :-)

In this Episode we are happy to talk to Grady Booch. We started off by discussing his Architecture Handbook, how it came into being, the progress, and how it will look like once it's finished. In this context we also looked at the issue of how to distinguish architecture from design. We then asked him about how "professional" software architecture is these days, as well as about the ubiquity of software product lines in industry. The next couple of minutes looked at the question of whether software development is an engineering discipline, craftsmanship or an art form, and we discussed the key qualifications of software developers. Grady then elaborated on the problems of developing in large teams as well as the potential limits of complexity we can tackle with software. We then got back to a more technical discussion, where we looked at model-driven development, DSLs, etc. and the role of the UML in that context. Next was a discussion about scripting languages, and the current trend towards new languages. We then looked at component marketplaces and other forms of reuse, as well as the importance of OO these days and the relevance of AO. We concluded with a (small) outlook to the future.

Changeable software has been a goal of several technique in software engineering. Probably the most important is Refactoring, changing the code without changing the behaviour (or at least without breaking the tests). In this episode Eberhard talks with Martin Lippert about this technique. The episode covers a history of refactoring, a definition of code smells and how to actually do refactorings in your everyday work. Also some advanced topics - like the ROI of Refactoring or Refactoring in dynamic languages - are covered.

This Episode is a round table discussion about Ultra-Large Scale Systems. In 2006, a number of authors (among them our guests Linda Northrop, Doug Schmidt, Kevin Sullivan, and Gregor Kiczales) have produced a report that addressed the following question: Given the issues with today's software engineering, how can we build the systems of the future that are likely to have billions of lines of code? In this episode, our guests discuss many of the issues that arise from this kind of system and provide an overview of the research areas that should be investigated in order to tackle the challenge. If you want to get more detailed information, you can read the ULS Report (PDF).

This is another episode on concurrency. We talk to two experts in the field, Brian Goetz and David Holmes about aspects of concurrency we hadn't really covered before. We start out by discussing liveness and safety and then continue to talk about synchronizers (latches, barriers, semaphores) as well as the importance of agreeing on protocols when developing concurrent applications. We then talked about thread confinement as a way of building thread-safe programs, as well as using functional programming and immutable data. The next set of topics covers various ways of how compilers can optimize the performance wrt. to concurrency, talking about techniques such as escape analysis as well as lock elision and coarsening. We then covered how to test concurrent programs and the consequences of the Java memory model on concurrency. We then went on to look at some more advanced topics, namely, lock-free programming and atomic variables. We also briefly discussed the idea of transactional memory. Finally, we looked at how better language support - specifically, a more declarative style of concurrent programming as e.g. in the Fortress language - can aid in improving the quality of concurrent programs.

This is the second part of our two part discussion of the eXtreme Programming development methodology. While the first part introduced the values, principles and basic practices, this time Arno and Alex speak about the practices that set the context for an XP project and how to get started, and they discuss some FAQs they often get when introducing XP.

In this episode, Gregor Hohpe gives us a great introduction to enterprise messaging based on his EAI Patterns book. Before we started discusssing the patterns in his book, we characterized messaging and talked about the various interaction styles. We also contrasted the messaging architectural style with an RPC based approach. We then took a look at the relationship to SOA, the role of contracts and the orchestration-vs-choreography discussion. We briefly discussed the nature of pattern languages before we then went through the different section in the book. There are six main sections: channel, message, routing, transfomation, endpoint as well as management and monitoring. We discussed the core patterns for each of these sections. This should give listeners a good high-level view of message-based systems. We concluded the discussion by looking at the critical importance of systems management and monitoring.

This is the fourth and final episode on the fundamentals of Software Architecture. We talk mainly about architectural styles and patterns, as introduced in the POSA 1 Book. We also discuss a little bit the process of actually using those patterns for architecting systems.

This episode is an interview with Werner Vogels, the CTO of amazon.com. We first talked about what scalability is, and which aspects there are to scalability. We then took a brief look at the technologies used at amazon, specifically, the middleware systems and the issue of vendor lock-in. Web services, and the role of SOA was the next topic. Then we covered what a service actually is add Werner explained the term "pizza teams". Testing and Deployment was the next topic followed by a look at architectural characteristics of scalable systems, the value of simplicity and the CAP theorem. We concluded the discussion with a brief look at the future of distributed systems

This episode is an interview with Steve Vinoski. Steve works as the Chief Engineer for IONA. He's what you'd call a middleware guru, he was for example deeply involved with CORBA. So, this interview centers mainly around middleware. We begin by talking about his own history wrt. middleare and ORBs and how ORBs evolved over time. We then talked about whether coarse-grained, stateless components might be a better abstraction for distributed systems than "objects". We then covered the future of CORBA, it's use in ethe embedded space as well as the practical relevance of the POSA patterns when building ORBs. Then we switched topics and addressed the role of web services as a "middleware middleware" and the maturity of WS-* specifications. We then looked at what Steve is working on these days, which is e.g. the Advanced Message Queueing Protocol (AMQP) as well as dynamic languages. We concluded the interwiew with his view on SOA.