Partial architectures are dangerous

Once development work begins on a project, there is no such thing as a partially designed architecture - there are only partially complete architectures and these are dangerous.  Let me explain the distinction and why it's important.

Firstly, let me admit that an architecture can definitely be partially designed - but only while the architect is working on it.  This can happen on whiteboards, on paper, in Visio, in the Visual Studio class designer, in someone's head or in any number of other places.

Risks of a partially complete architecture
When development work begins, it will (hopefully) be in line with the current view of the architecture.  As soon as the first line of code is written, modifications to the architecture have to be called "changes" - there will (most likely) be changes required to the code to bring it in line with the new architecture.  And here's the key point - it's a new architecture.  It's not just the old architecture fleshed out a little bit.

Now you may think I'm splitting hairs here, but once development work begins it gets increasingly more expensive to change the architecture.  This exponential increase in cost generally continues as development progresses.  So revisions to the architecture can be costly.  And this means there's a temptation to cut corners, which would translate into the development team not changing the code to completely match the new architecture.  If this happens, you'll have a hybrid architecture which is neither the old one or the new one and heaven help you when you want to change the architecture yet again!

The other real risk of a partially complete architecture is that one of the developers may get to the "edge" of it and try to keep going.  In other words, they will encounter a problem, realise that it isn't handled within the current architecture and come up with their own point solution to it.  When a different developer hits the same problem, communication within the team may or may not be good enough for them to realise that it has already been solved.  If it isn't, then they will also come up with their own solution.

Am I being too precious?
Now I know that so far I sound quite precious about my architecture design, as if I don't want other people making decisions.  That isn't really the case.  I just want to be involved in the decision-making because it's my responsibility to try and ensure that all the decisions contribute to the bigger picture.  As David Armour writes, agile development teams can often just plough ahead delivering functionality without giving any thought to architecture.  This is the kind of project that I don't want to be involved in.

I'm also trying to mitigate the risks of a lack of development discipline (i.e. architectural changes not being completely worked through) and poor team communication (i.e. the team doesn't know that a particular problem has already been solved by someone).  Isn't it strange how these "soft" issues can have very direct impacts on our development processes?

Is there another way?
The other point I should make, is that some project teams take a different approach to this problem.  James Shore talks about Continuous Design and the mindset you need to operate in this way.  This approach sounds appealing to me, but still doesn't get around the fact that somebody has to have the bigger picture view, they have to know that it is accurate and they have to let it influence the decision-making process.

August 15 2006
blog comments powered by Disqus