Idle Thoughts

Is software engineering really engineering?

I’ve followed a more unusual career path than most into software development, having qualified as a mechanical engineer and spending the last few years working in both engineering and construction on such things as alumina refineries and sewage treatment plants before my current work.

I half-jokingly tweeted that software engineering was a less than a full engineering discipline, reflecting the skepticism that traditional engineers reserve for new-age engineering disciplines such as safety engineering, software engineering and “mechatronics” engineering - whatever that might be. We particularly reserve such skepticism for occasions where we’re in the presence of such an “engineer”, and can use it to get a rise out of them.

(In reality, engineers don’t participate in semantic games about what is or isn’t engineering - judgments are made on a particular person’s competence, and as long as they’re good at what they do, they can call themselves “wheelbarrow” and it wouldn’t make any difference).

Stilgherrian replied that:

I’m happy with “software engineer” if engineering-level disciplines are followed. UNSW teaches that.

While the definition is a little tautological, I did check out UNSW’s software engineering syllabus, and didn’t find anything unexpected: UML, traditional waterfall processes, requirements documentation etc.

It was at this point I realised what was annoying me about Stilgherrian’s definition: the reduction of engineering to methodology. This isn’t just a problem in the perception of software engineering. Bricks-and-mortar engineering is infected with the same obsessions, from PMBOK devotees to 6-Sigma fetishists and a thousand other theorists who think methodology paves the golden path to engineering perfection.

A broader definition of engineering is needed than merely claiming it’s the application of scientific and technological knowledge. Perhaps this was acceptable when James Watt was making his steam engine, but it’s a woefully poor definition for today. I’d say a better definition is that engineering is the contextualisation of scientific and technological knowledge for a specific purpose, and that context must encompass social, economic, ethical, cultural, psychological, political and environmental dimensions, and probably another dozen more besides.

I offer this definition because it reflects current engineering practice. Engineers must be strong critical thinkers with an extensive knowledge of that context in which they and their designs must operate. Merely plugging numbers into spreadsheets or following steps in a process is not sufficient, and engineers who do so are rightly derided.

Engineering must encompass some methodology, but that in-itself is nowhere near sufficient. It seems to me that a lot of software engineering (UML / CMM / Agile) etc is nothing but methodology, divorced even from the outcomes they purport to achieve, let alone being able to place the acts of software development in that wider context. And I think much of what is called software engineering would fail that test of contextualisation: the Therac-25 was a massive failure to understand context, compared to, say, Roger Boisjoly’s actions in attempting to prevent the launch of Challenger.

So is software “engineering” really worthy of the title? Well, I’m not going to answer that, except to observe that a lot of things are called “engineering”, both in the world of software, and the bricks-and-mortar one. And some of them probably shouldn’t be.