July 13, 2007

...Learn TDD with Codemanship

The Agile Architect

Contrary to - well - pretty much the entire software industry, I don't believe that a software architect is someone who designs software. I believe that a software architect is someone who recognises a good software design when he sees one.

A bit of probability and statistics - backed up by a heap of industry experience - makes it abundantly clear that even "waterfall" projects have to iterate if they want to deliver a workable solution.

Evolution is a very effective search algorithm for finding solutions to complex problems, and that's why evolutionary design is the de facto process for creating software solutions to all but the most trivial problems. Even when we deny that we're doing evolutionary design, we are - in reality - still getting feedback and iterating towards something that's fit for purpose (even if it's all scrunched up into the last 30% of the schedule, or if it happens after the first release when the change requests inevitably come flooding in).

In evolutionary design, the way we select which parts of the design to keep and which to change with each iteration are a critical factor in how quickly we can reach an optimum solution. Quality of feedback is one of the keys to success in evolutionary design.

And since all software design is, in reality, evolutionary, then quality of feedback is a very necessary ingredient in any software project.

Development teams can get feedback about functional fitness from end users and from testing. On waterfall projects, what tends to happen is that this feedback is deferred until very near the release date, at which point the feedback starts flooding in and a frantic process of iterative change kicks in. This is often where most of the actual value of the end product is delivered - the stuff the team should have built. But even waterfall projects - using this user and testing feedback - can evolve the code towards something that's kind of, sort of (in a certain light, if we screw up our eyes really tight) useful and usable.

If only our end users or system testers could as readily submit bug reports saying things like "the accounting component is unmaintainable" or "the user interface shouldn't be dependent on the data access layer".

And on most projects, those kinds of design quality bugs - and they are bugs, just not the kind users can see (though users will be indirectly impacted by them eventually) - don't get reported by anybody. So, without design quality feedback, the evolutionary process does nothing to iterate towards a better internal architecture. Which is exactly what we would expect. And, unsurprisingly, that's exactly what happens, in real life.

An architect - let's call him an Agile Architect, just for jolly (hey, how about a "Post-Agile Architect"? Yeah, I like that even better...) - is someone who provides feedback about software design quality. Just as a user knows that you have to open a customer account before you can raise an invoice for that customer, an architect knows that a method shouldn't have more than 10-20 lines of code in it, or that a class should have a single reason to change, for example.

The people who write the code do the design. The architect is the software design domain expert who provides frequent, timely and objective feedback about the quality of the code being produced. In some respects, it's essentially another testing role.
Posted 18 hours, 32 minutes ago on July 13, 2007