Why Software Engineering Isn’t Engineering, and the Implication for Deadlines

questionmarkSoftware engineering estimates and plans often fail to live up to the reality that follows. It seems to be the only engineering discipline in which this is the rule rather than the exception.

Before you leap to the defence of software projects you’ve worked on — perhaps even your own — think about how many times those projects delivered precisely what they said they would, and in the timeframe they originally promised. If yours did, you’re probably in a happy minority, or you’ve already embraced some of the realities I’m highlighting below.

“Engineering”… Really??!

Other than for extremely formal cleanroom and safety-critical systems, the flavour of software development undertaken in most companies isn’t really an engineering discipline at all, despite our ambitions to call it that. But the real problem is that we still predominantly estimate work and plan our activities as if it was, either within the software team or in our interactions with the wider company and its goals.

We architect and break down systems into subsystems, components and tasks, then estimate the resources required for each task. At the end of it all, we are usually surprised when our estimates don’t reflect the reality of what comes next. It is clear that the wider business is often similarly surprised and, therefore, no wonder that software estimates are often viewed with skepticism and disbelief.

Roads, Bridges, Bricks & Mortar

In physical engineering (such as civil or mechanical), estimates are based upon abstractions that are known to be quite accurate and dependable; component parts integrate and combine in ways that are by now well-understood. Each level is based on a foundation that is, at the lowest levels, ultimately based on well-researched principles: physics, chemistry, metals, concrete, glass, water, soil, gravity, etc.

Even the introduction of new modern materials is relatively risk-free as they can be tested, studied and understood in isolation or smaller builds, then integrated into larger builds with fairly predictable results.

That’s not to say that physical engineering doesn’t have it’s delays, complexities and flaws… but at least there’s the possibility of attempting to plan, reason and engineer them out.

Building on a Foundation of Complexity

Teams building software seem to ascribe the same physical characteristics to it as if it were more formal engineering. Whilst it is certainly true that there may still be physical laws governing the electronics and other hardware the software ultimately runs on, most software is built at a level of abstraction several hundred layers above that, and therefore on a foundation of potential complexity we may not understand quite so well.

Even where component parts of our system are well-understood (operating systems, languages, libraries), they can interact with one another, and with the foundations they in turn depend upon, in ways that components rarely would in a physical build.

Add to this the fact that most of our abstractions are about systems the precise likes of which we may have never personally built before, and it becomes clear that we are, at best, working with assumptions.

It seems we often mistake our ability to envisage a final system for the reality of the way that system will actually need to function, and the work involved in building it.

Complexity Appears Late

Problems and complexity appear notoriously late in software projects. Attempts to get an early understanding — such as proofs of concept, or use of spikes in the Agile world — can help, but they often don’t uncover the reality of the actual system we’re building… just one similar to (and therefore potentially totally unlike) it.

The result is that reality rarely adheres to our estimates and plans.

So What?

It is probably high time that we admitted most software engineering isn’t actually engineering, in the strictest sense of the term. The implication is that our estimates and plans — and our ability to hit deadlines — shouldn’t be relied upon in the same way. Embracing this truth, company-wide, might help us.

Secondly, I’d say that Agile, yet again, has something to contribute: We already know that it helps to nail requirements by working in an iterative and evolutionary manner alongside a customer, but it also assists in handling complexity and planning, by removing strict estimates and by working iteratively.

Most Agile “stories” are planned in points, t-shirt sizes, and other schemes, in an attempt to get away from time-based estimates and instead plan based on the perceived complexity and past ability of the team to deliver similar stories. Agile’s iterative approach means we can adjust course as complexity and other problems appear, just as we adjust course by regularly showing early versions of a system to a customer.

One implication of accepting this is that software projects will be notoriously hard to plan against calendar deadlines. This means the wider company will need to work with software teams in a way that depends less upon deadlines, estimates and plans. Many organisations embrace Agile in their software teams, but not in the wider company. This creates the untenable combination of Agile software work practices, but rigid / calendar deadlines and deliveries to the wider business… and the largely unacknowledged fact that these two worlds seldom align.

Maybe it’s time we embraced the reality of this less-than-formal “engineering” activity of ours, owned up similarly to the reality of our less-than-dependable “estimates”, and relied more on ways to work with these truths, such as Agile? This may finally mean embracing Agile in a truly company-wide manner, rather than just within software teams.


  1. says

    Having been a Researcher in a past life, before becoming a Software Engineer, I would agree that Software Engineering is perhaps closer to Research than to Exact-Science Engineering.

    After all, by opposition to, say, bridge building, or chemistry, we are working in a domain that shifts constantly. No matter what project you are undertaking, you can be sure that the bases on which it is built will have changed before you hit midway. You can also be sure that any theory or design you have will not survive contact with the execution.

    • says

      Thanks, yoric, that’s a great point. My post has stirred up a great deal of debate about whether software development is “engineering”. Seems a 50/50 split of opinion. I was certainly taught (and still agree) that it is more like Research, despite the job titles they may give us.

  2. says

    I think this comes down to a few different things. The same could be said for people who write software and call themselves “architects”. Many of these titles feel invented for social and cultural adequacy reasons, both outside and inside of the software industry.

    That’s a really interesting observation by yoric, as well. I had never considered research as a base practice to building software, but it’s certainly worth a more comprehensive review.

    Great article overall, Ian. Thanks for sharing this.

    • says

      Thanks Kevin!. Yes, it certainly stirred up a great deal of debate over on Hacker News. The definition of “engineering” is one many folks seem to have battled to attain, and others are battling to defend. Great debate!

  3. says

    Software engineering could be engineering if the “engineers” (developers) were actually more in control of the product instead of often being under the force of higher management to deliver a product by a certain deadline. If we were building a bridge and said “well, we could take this shortcut but thousands of people *might* die” that wouldn’t fly. Software has the horrible disadvantage that it can be patched, updated, and redesigned, allowing customers to be delivered a half-finished experience on exactly the day they were told it would come out. The world is being flooded with poor quality software because software engineering SHOULD be engineering, but lazy people and bad managers have said it’s not.

    Just my opinion.

  4. says

    I think this article would benefit from a definition of what you think real engineering is. Engineering that is always on time and delivers the exact specification – nothing more, nothing less – is generally very boring, run of the mill ‘manufacturing’ or ‘fabrication’ type work.

    As an engineer that does software development I believe engineering is the application of science and math to deliver efficient solutions to problems. The implication through efficiency is that there are tradeoffs – engineering is balancing tradeoffs. That’s why in physical engineering there are load factors and safety buffers at all levels of a delivered product no matter what discipline you work in. Civil engineering build bridges to carry far more load than requested, electrical engineers deliver power systems that can buffer against much larger spikes.

    I would probably say that just like web developers might think that games developers are the smart developers and in turn game developers might think kernel developers are the real developers, software engineers might fall into the trap of thinking that ‘physical’ engineering is the real engineering.

    All difficult engineering hits issues that humans didn’t foresee. Which is to say that all humans solving difficult problems hit issues they didn’t foresee at the beginning of solving the problem.

    All that being said there are definitely people getting around using the E word with reckless abandon. I do not think that being a software developer precludes you from being an excellent engineer, using those principles and delivering your goods on time and to spec but if you want to call yourself an engineer you should have to prove it. Perhaps it should be a more protected word like in Canada – I would like that.

    I hope people don’t have some idea that civil, electrical or even computer engineers just do their work with more rigor. It’s a choice to do good work and ‘real’ engineers, software developers and software engineers all have an opportunity to do that.

  5. Bryan R says

    In my experience, the act of building software to solve a problem is distinct from traditional engineering disciplines through the amount of logic used in the construct. This is distinct from design. Building a bridge or even building a microprocessor is a lot closer to scripting with limited use of language elements that make the language Turing-complete and therefore subject to the halting problem. Without the use of conditionals to make the software solution modal (a bridge and a clock are not modal), is scoping the work much more reliable? Is the complexity that you describe in your post attributable to the halting problem or not? In my experience as both a full-stack software engineer and electrical engineer (with a heavy side of applied physics for fun), my scoping estimates are accurate when the software connects known libraries or tools without making the software explicitly modal. Unfortunately, these projects are either really easy or explicitly research heavy to discover the right pieces and their limits (ie spec sheets). Only a small percentage of my work falls into either category because the advertised specs are incomplete or wrong so it falls to original logic that is definitely using language features that make the solution subject to the halting problem. It definitely resembles basic research at that point, which blows past deadlines regularly.

  6. Brandon says

    Computer science and software engineering are infantile compared to the likes of physics and bridge building. I think, in time, that will change.

  7. John says

    A good software developer can make solid schedules and functionality and deliver. When was the last time you heard a manager say “That’s too soon, move the date out and remove function?

    Electrical engineering is no different, business pressures demand accelerated schedules and extra iterations. Low yields also result in high costs. That can be attributed to manufacturing, but design can also be a cause.

  8. says

    This is an important topic, and I mostly agree with the sentiment. In the grand scheme of things, programming is an extremely new discipline, and we’re still quite far from anything resembling engineering, or the ability to predictably produce systems that can be reasoned about effectively. Particularly because we’ve strayed from the mathematical principles from which the theory of computation itself was derived.

    However, I wanted to point out that a rigorous comparison demands that we acknowledge similar failures in analog disciplines. Construction projects from private residences to major public works projects break budgets and schedules on a regular basis. Sometimes by orders of magnitude (see: https://en.wikipedia.org/wiki/Big_Dig).

  9. says

    Maybe your real point — we can improve the accuracy of estimation, maybe using Agile methods — should be the focus of this article, lowering the temperature of the headline (a conclusion this article fails to successfully argue for)

  10. says

    The tenet of this article is correct.
    It has been around for a while “The Mythical Man Month” being a testament to that; there are others.

    If I decided to be a GP tomorrow, it would take me 7 years of study and practice give or take…or say if I wanted to build actual bridges it would take a heck of a lot work based on sound principles that need to be taken on board, before i could even start thinking about one.
    Yet, I have met, models, technicians, lawyers and even doctors, that either implicitly or explicitly decided to get into I.T. for various motivations; if you call yourself and “I.T. Expert” no one could even start to dispute that.

    I.T. is a trade…its not a profession nor is it anywhere close to an engineering discipline. I doubt it would ever be so; never say never, right?

  11. Anonymous says

    Yeah but even physical Engineering wasn’t like that in the beginning. It takes a lot of time and effort to get the abstractions in place.

  12. says

    Large body of knowledge showing estimates in nearly every other domain also as problematic as in software. Start with Bent Flyvbjerg’s. Also all the Root Cause Analysis of Nunn McCurdy breach and Over Target Baseline assessment of US DOD, DOE, NASA, UK MOD, and Australia MOD programs.
    The conjecture that SW Development is unique in this problem, is not supported by the evidence.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s