About ten years ago I had the job title ‘Software Engineer’ and I occasionally still describe myself as a ‘Software Architect’. However, I am not entirely comfortable with being described as either. I have taken to using the title ‘Technical Navigator’ because it suggests steering through treacherous waters, and no one really knows what to make of it!
The reasons I am uncomfortable with all analogies to engineering and construction are many but the primary reason is ‘physics’. Civil engineering is constrained by the laws of physics. With some notable exceptions I will elaborate later, most business led software development is not constrained in the same way.
Those of you who know me personally will have heard my oft repeated phrase “unlike software ‘engineering’ when they were constructing the Tyne Bridge, someone didn’t widen the Tyne by 300 miles (and simultaneously relocate it to the South Pole)”.
During software development it is the norm for the sponsors to add and remove requirements. Even more frequently, they don’t really know what to ask for, or how to ask for it. Even when they do, they don’t really know if the customer wants or needs what they are suggesting until it’s built and shipped. We can’t blame business sponsors for this. The world moves at a tremendous pace and we Software Developers are one of the primary reasons why!
The same sponsors believe that software development is as well understood as civil engineering, and expect the same predictability. However, they over estimate this predictability. How many civil engineering projects over run time and budget?
In reality, software development is probably at the stage of architecture and construction in Western Europe in the early Middle Ages. We sometimes construct some spectacular Cathedrals, but for every one of those there are hundreds of wonky, subsiding, crumbling shacks that keep the worst of the weather out, but leak and lose thatch in a strong breeze. To (over) stretch the analogy, all of these buildings need maintenance to stay fit for purpose and we keep adding outbuildings and extra chimneys as the families living in them grow.
There are plenty of examples in history of civil engineering following similar patterns to large software code bases.As an example consider one of my favourite buildings, Ely Cathedral (just up the road from where I grew up).
Ely Cathedral is a splendid edifice, with a unique Octagonal Tower. However, it didn’t spring fully constructed from the Cambridgeshire Fens over night, and it didn’t (still doesn’t) survive without constant maintenance.
It’s construction began in the 11th Century (1083AD) and it didn’t reach it’s current form until the 16th Century. Since it’s initial construction, arches and buttresses have been ‘tacked on’ to shore up parts of the building, two transepts and the Norman Central Tower have collapsed.
What has changed in modern civil engineering between now and what the medieval stone masons did is the growth of the fields of mathematics, physics, material science, etc. Civil Engineers now understand the laws and constraints within which they need to work.
In Software Engineering we are still finding and pushing our limits. With the exception of software that actually is constrained by physical limitations, like guidance systems, ultra low latency distributed systems, etc., we are still unclear what are the limits of the materials we are using or the environments we are using them in.
I have high hopes of the current movement towards the pragmatic application of functional programming, persistent immutable data structures (and databases) and the promise of fields of mathematics, like linear logic, to help solve some of the problems of distributed systems.
However, I think we are still in the early middle ages of computer science, as Dr Philip Wadler says, “you don’t put science in your name if you’re a real science!”, and I don’t put ‘Engineer’ in my job title as I’m not a real ‘Engineer’.
Leave a comment