Behind the Scenes at Global-Roam

Fuelled by Stephen’s glowing recommendation of the Thoughtworks presentation “Emergent Design & Evolutionary Architecture”, I went along to Neal Ford’s repeat performance in Sydney this morning.

The talk presented some very sensible sounding ideas on software “design”, and few more on “architecture”. Stephen has covered some points that stood out for him in his post, and here are a couple more that I consider worthy of mention or additional comment.

Software is not a Bridge

Ford articulated a few points in Jack Reeves’ article “What Is Software Design?” (which I haven’t yet read in full) that apply as much today as they did 8 years ago.

• The final goal of any engineering is some kind of documentation (the “design”) - once the documentation is done it is passed on to manufacturing to be built
• In software engineering the design document is the source code, and the manufacturing process is linking and compiling
• Software is expensive to design, and essentially free to build (manufacture)
• Therefore the cheapest way to verify the design is to build and test (this of course does not work so well for bridges)

Stephen has already mentioned that “requirements gathering is a lossy compression algorithm”. You start with an idea about what you want/need, it is compressed into requirements (and information is lost in the process), then the requirements are “re-hydrated” back into code (in which the developers must try and fill in the gaps in the requirements to recreate something like the original idea).

Conclusion: Get from the idea to the code as directly as possible, then build and test. Emergent design and evolutionary architecture (and Agile principles/practices in general) are ways to do this better.

Emergent Design

When you start designing software, there are unknown unknowns which make it difficult (if not impossible) to design a perfect solution upfront. Emergent design is “doing enough design to get by until you work out what you didn’t know when you started”.

Abstracting too early is just speculation without facts. Emergent design is about “effective” abstraction - discovering abstractions and idiomatic patterns in your code that work, and reusing them. Idiomatic patterns are not the Gang of Four design patterns, but are ways of solving problems that work well for the problem or enterprise in question (and therefore should be abstracted for reuse).

Ford posed the question - “how do you know when to abstract?”. And the answer - “experience”. An experienced architect is someone who has seen enough to know what’s good/bad. It is difficult for someone to explain exactly how to do this because the knowledge and understanding required to do it is innate.

There were additional points here about technical debt and complexity (which Stephen has covered), TDD, refactoring and code metrics (most of which we have already found from other sources).

Evolutionary Architecture

Ford explained that architecture must “evolve” (rather than “emerge”) because it has to be there from the beginning.

I personally have never been clear on the difference between design and architecture (which would be required to understand the need for the different verbs). Ford offered a few definitions pulled from the article “Who needs an architect” by Martin Fowler, ending with the chosen definition - “stuff that’s hard to change later”. I haven’t been able to work out what “evolutionary” architecture is (yet) to a degree that would make this information useful, but there is a technical explanation in this IBM article.

Build vs Buy

The question of whether to build or buy software for some of our internal systems has been on my mind for quite some time. Ford offers this flowchart as a method of answering the big question:

The key point is that software that meets a strategic need should be built. If the software will perform a commoditisable business process (aka. overhead), then you can consider buying. Software should only be bought if it is useful to the business straight away (without requiring customisations which can take a significant amount of time), and if it is extensible (as opposed to merely customisable).

For us, this means we might consider buying our Customer Relationship Management system, but if (hypothetically) we wanted to make our licensing system a strategic point of differentiation, then we would need to build it.

In Closing

Emergent design and evolutionary architecture is all about delaying decisions until the last responsible moment, to minimise unnecessary complexity, to give your software projects the best chance of success.

The presentation had a few nice lessons, but it was just an overview of the subject - there is much more detailed and practical information on “doing” emergent design in the IBM technical library.

Tags: Agile Software Development, software architecture, software design

This entry was posted on Tuesday, February 23rd, 2010 at 8:48 pm and is filed under Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.