Broloco

For a few years every project I have started has, what some of my colleagues and I have termed, a Technical Architecture Specification. This document sits alongside the standard Requirements/Design Specification, and aims to describe the "how" of the system rather than the "what". It describes the "shape" of the system and is written with express reference to the design patterns used and as such requires a little bit of knowledge to make best use of it.

Unfortunately though, every Technical Architecture Specification I have ever written has been criticized. Not for its content I may add, but more for the very nature of the document itself. I've been faced with the same arguments time after time: where's the benefit in this document; will the customer understand it; why all these design patterns? So, of late I've started to have second thoughts as whether I should produce this document after all, it doesn't really cause me any problems if I don't write it, I know how the system should work!

Thank goodness then, I read this blog entry to help erase my doubts: (http://www.ddj.com/blog/architectblog/archives/2006/09/who_needs_a_sof.html)

Since software development first reared it's head way back in the 50s and 60s the industry has been in search for a metaphor that fits.

For years the industry flogged (and still continues to flog) the idea that software development is a manufacturing discipline. I for one however, firmly believe that software development is NOT a manufacturing discipline.

One of my favorite definitions of manufacturing reads as follows:

• to produce in a mechanical way without inspiration or originality .

Software development couldn't be further from this definition if tried! The development of software requires inspiration and creativity and the only element of the process that could be truly considered mechanical, is the bit where we hit F5 or type nant at the command line and our design becomes reality.

Yet still people both outside and inside our industry still cling to the idea that software development can be reduced to the mechanical. This idea has seen countless management guru's making a fortune selling methodologies that promise “follow our process and every software development project you undertake will be a success”.

What the software development industry seems to be unwilling to accept is that software development is hard. No amount of process or fancy tools really takes much away from this inherent difficultly. Sure it may become slightly easier, but ultimately if the developers don't engage their brains and work, every project will fail.

Fundamentally I believe software development is a creative and communicative process. It requires those involved to think, generate ideas and communicate those ideas to others.

For too long now software development has considered itself the younger brother of engineering and manufacturing disciplines and has attempted to follow their examples. However, when I look at software development today I cannot help but think it's time we stopped trying to justify our existence by trying desperately to relate to others.

Software development is starting to grow up and it's time we followed our path.