At OT 99 (that’s Object Technology 1999, now known as SPA for Software Process Advancement) I attended a session by Kent Beck called Software is Software – Beyond the Horseless Carriage. The basic premise of Kent’s talk was that it was about time the software business “grew up” and its practitioners recognise it for what it is, a discipline in its own right which no longer needs to continuously borrow terms and techniques from other industries and disciplines. The title of the session refers to the time when the automobile was first invented and people called them horseless carriages because horse-drawn carriages were the only frame of reference they had. Unfortunately, 12 years later, I don’t think we have quite got around to jettisoning our horseless carriages, especially in the upfront work that is done in trying to map out the major system components and their relationships, sometime referred to as architecture (a word which itself is borrowed from another profession of course). On the face of it this may not seem to be a problem; after all those other industries (civil engineering, auto-engineering even film making) have been around a lot longer and so must be able to offer good advice and guidance to the business of software mustn’t they? Actually, I think there is a problem and Kent Beck was, and still is, right.

• The business of ‘making’ software is fundamentally different from any other human endeavor. Software is infinitely malleable and potentially changeable right up to (and sometimes after) it has gone into production. No other engineering discipline has that flexibility. At some point drawings and blueprints have to be signed off, factories and production lines have to be built, building sites prepared and production begun. After this any change becomes prohibitively expensive. With software the perception (and sometimes the reality) is that code changes can be made right up to the moment the software ships.
• Most other engineering disciplines have fairly well defined job roles, often with their own professional organisations, training programmes and qualifications and well understood and mature tools. These roles are usually carried out by separate individuals (in the construction industry it’s unlikely the architect will roll her sleeves up and start laying bricks).
• The engineering and manufacturing approach, or process, is by and large pretty well understood and has been refined over a long period of time (sometimes hundreds of years). The approaches can be taught and are an integral part of the role of being an architect or aero-engineer. Further, these approaches are built around a common language which is also taught and well understood by its practitioners.

A rigorous approach to the field of software architecture needs to recognise the differences whilst at the same time understanding its constraints and build a solid, engineering based approach to its development. This should include killing off the endless debates of agile versus waterfall or structured versus object-oriented and any of the other interminable ‘religious wars’ that we seem to love embarking on and focus in on what matters: applying IT in a reasoned and structured way to solving real-world (and sometimes complex) business problems.

As we enter the new year lets celebrate the field of software development for what it is and help forge the right amount of rigor and discipline in creating a ‘proper’ profession that finally loses the shackles of all those other industries. After all as this guy says (far more eloquently than me) “the processor is an expression of human potential” and is “akin to a painter’s blank canvas” (see this great drawing). I’d like to think of us architects as the painters ready to fill that canvas with great art. Oh heck, but that means we are now comparing architecture with art and that would never do.