Sessions at Software Architect 2011 about Software Architecture on Wednesday 19th October

Computer science is built on a shaky tower of abstractions, but we’ve been distracted by other things until we believe it is reality. This talk teases apart some of the tangled abstractions that have become so common they are invisible yet impact important decisions. I cover languages, tools, platforms, and burrow all the way down to fundamental concepts. This wide-ranging keynote answers these questions and more:
• Why does my keyboard look the way it does?
• Why is the iPad the most revolutionary device in the last 30 years?
• Why do some people hate Maven so much?
• How can I choose technologies with long shelf lives?
• Is hiding always a good thing?
Oh, and some jokes too.

Technical debt is the cost of putting off good development practices. This debt must be paid back to avoid the “interest payments” becoming crippling.
This presentation will further define technical debt, before examining some anti-patterns and how to avoid them. We’ll then look at how to put a financial cost on technical debt, and end by examining some measures to identify technical debt in a code base.

Design patterns do not exist splendid isolation. In the real world patterns overlap one another and interact in complex ways. This class takes a unique approach to teaching patterns by analysing a real computer program in terms of the patterns used to implement it.
We’ll look at how the design patterns are actually used in practice, and see how the strengths and weaknesses of the patterns play off one another. You’ll also get a chance to see how real-world realisations of the patterns can differ from the Gang-of-Four examples and how a given pattern can be implemented in various ways.
The examples are in Java, but C++ and C# programmers should have no problem following along. Some familiarity with the Gang-of-Four patterns is assumed, however (you should, at minimum, be able to identify them by name).

The code might be the architecture but at some point in time you’re going to have to explain how it works, and that’s when the whiteboard pens make their appearance. Where do you start though? How much detail should you include? Technology decisions included or omitted? UML or block diagrams? Join us as we look at some typical diagramming bloopers and show you how to produce effective sketches.

TDD seems to take all the credit for getting software designed right these days. But how do you approach a User Story or a whole application with TDD? Use UML? Right – except hardly anybody does. So let’s get real: whoever said object orientation would make designing software easy, was wrong. OOAD, UML, even Clean Code are not easy, not even intuitive. Enter flow-orientation. If you temporarily give up any fixation on “real” objects there is a way to escape many design difficulties. Want a design that is easily readable? Want a design method that lends itself to teamwork? Want a design method that can describe software on any number of abstraction levels – and can easily and losslessly be translated into code? Want designs that result in code that can be tested without mock-ups? Flow-oriented designs promise to give you this and more. It’s designing software the smart way; it brings out the best in groups. And there is still a place for “real” objects. Promised.

This session describes the current thinking about emergent design, discovering design in code. The hazard of Big Design Up Front in software is that you don’t yet know what you don’t know, and design decisions made too early are just speculations without facts. Emergent design techniques allow you to wait until the last responsible moment to make design decisions. This talk covers four areas: emergent design enablers, battling things that make emergent design hard, finding idiomatic patterns, and how to leverage the patterns you find. It includes both proactive (test-driven development) and reactive (refactoring, metrics, visualisations, tests) approaches to discovering design, and discusses the use of custom attributes, DSLs, and other techniques for utilising them. The goal of this talk is to provide nomenclature, strategies, and techniques for allowing design to emerge from projects as they proceed, keeping your code in sync with the problem domain.

The Managed Extensibility Framework, or MEF for short, is an excellent way of structuring applications in .NET. This session focuses on how you might use MEF as more than just a simple IoC container, examining everything from the basics of importing and exporting parts through to dynamic re-composition and flexible deployment catalogs.
MEF is a rising star in the .NET firmament. Come to this session to see how it might fit into your application architecture.

The service pattern is pervasive – either operation centric (aka SOAP) or resource centric (aka REST). The security challenges are the same in both worlds – authentication, authorisation and secure communication. Common scenarios are direct authentication (like passwords or client certificates) as well as brokered authentication where the identity provider is external (at least to the application). This talk walks through those common scenarios and shows the architectural and technical approaches to design and implement those services in a secure fashion.

The title of “architect” has historically been a sought-after title on one’s business card and resumé. This is, in part, a natural outgrowth of the way that architects employed in the construction of buildings have been revered over time as the smart and creative “brains” behind important endeavours that last over time. But modern software development processes, such as Agile, Scrum, and eXtreme Programming play down the role of grand upfront design. Does that mean that software architects are no longer needed? We’ll explore the role of the architect in modern process, and suggest why such individuals are needed as much now as ever before, with perhaps some changes in approach to the work at hand. The session will be conducted as a presentation followed by roundtable discussion.

For an Agile project to be successful, the architecture of the system has to reflect the needs of the process. You simply won’t be able to refactor constantly, accommodate changing business requirements, and so forth, unless your system is designed to accommodate those practices. This talk will look at the characteristics of an Agile design, and explore several design principles that will keep your design on track in an Agile environment. We’ll look, specifically, at the Single-Responsibility, Open-Closed, Liskov-Substitution, Dependence-Inversion, and Interface-Segregation principles.

In this session we’ll look at a number of common mispractices and misconceptions that the speaker has seen in his 20 years of experience using design patterns. Together, we’ll examine them and look at fixes for them, so that, by the end of the session, you will no longer suck at design patterns. :-)

Despite what some developers think, we spend a lot more of our time reading code, code that was often written by someone that isn’t around anymore. How do we deal with this common scenario without resorting to burning our predecessor in effigy? Better, how can we write code in such a way that our successors will heap effusive praise upon us at the mere mention of our name? During this talk, we’ll read actual code and discuss ways it could be improved. As we work through real examples, we’ll explore the importance of patterns, principles like SOLID and SLAP, and essential practices like unit testing and continuous integration.

The more vocal in our industry would have you believe that all software teams consist of agile test-driven craftsmen using the latest and greatest technology. This is the real world though, and a number of things often get in the way. This session puts you in the shoes of somebody that has been asked to rescue a struggling .NET project. What are the problems and how would *you* put the project back on track?