Senko Rašić

Is software development a proper engineering discipline? On one hand, it looks like it should be – computer science is a rigorous, hard, math-based science. The hardware is deterministic.

As anyone involved with the discipline will attest, though, it's sorely lacking. Just Google for “if programmers made ...” or “if software engineers built ...” for the cheeky, but not entirely untrue, comparisons.

Why are we so bad at it? Is it because we're really struggling to be something we're not? Or are there other reasons we're failing?

Let's do a cheeky comparison of our own.

Bridging the gap

Suppose you want to build a bridge. Right off the bat, you know a few things:

• which two places across the water you want to connect
• how many lanes and of which type (car, train, bike, pedestrian) you want to support
• terrain on both sides and the weather patterns
• typical building materials for the bridge and their properties

Based on this, you can design the bridge architecture. It'll probably go through a few iterations – maybe number of lanes will change based on the cost projections.

During the design, you'll never:

• cheap out on the architects – it's vital you get this right and the design phase cost is small compared to the overall project budget
• rush the design phase – most of the calendar time is spent chasing around stakeholders (getting people to decide on building a bridge in the first place, chasing permits, etc) so there's no need to rush the architects

Once everyone signs off on the plans, you know exactly how and what to build, down to the bill of materials. Then you go and build the bridge.

Once it is built, it is done, except for regular maintenance. The terrain doesn't change, the materials don't change their properties, and you definitely don't attempt to move the bridge or add another lane in a year.

You also don't expect terrorists to be attacking the bridge, and you usually don't account for once-in-a-thousand-years natural disasters. If you try to, you'll be accused (correctly) of over-engineering and being insecure. There are standard safety factors and you don't need to go over them except for a very good reason.

I'm not a civil engineering myself (I have a bit of background in mechanical engineering), but I don't think any would find the above description and assumptions wrong. Simplistic, yes, wrong, probably not.

In contrast, in software development you often:

• don't know the exact requirements, or they will change throughout the development process
• want to keep the software as configurable and adaptable as possible (no hard limits on the number of users or amount of data, for example)
• can't account for all the differences in the platforms your software will run in (either native desktop/mobile, or across web browsers)
• deal with platforms or frameworks that change rapidly and in a ways that make you rethink the design of your software
• need to interact with poorly specified and/or poorly working 3rd party components (even if they work great, network stability can always be a problem)

What's more, with software:

• we expect to need it to change – either to evolving business realities or to keep up with the underlying platform changes
• we expect it to be reasonably robust against malicious attacks

In contrast to civil or mechanical engineering, when we talk about “designing the solution” in software development, we talk about having a high-level architecture with roughly fleshed-out components (what they are, what they need to interact with). It's not even close to the level of detail the architecture plans give the bridge builders.

This means that the design phase in civil engineering doesn't map to solution design in software development – it actually maps to the entire programming effort, which is the bulk of the work, cost and time in any software development project.

        +------------+-----------------------------------+
BRIDGE  |   Design   |              Building             |
        +------------+------------------------+----------+
 APP    |             Programming             |   Ops    |
        +-------------------------------------+----------+

Copying bridges

Ok, you build one bridge. How hard is to build another just like it? Well, you repeat the whole process again in its entirety. Hopefully you do reap some savings due to the fact that you're now more experienced and have established supply chain connections, but that's it. The majority of work is still there and if everything else stays the same, the budget won't be very different.

In software development that's – you just make (or deploy) a new copy. Done!

What does this mean for builders themselves? This means in civil engineering you get more money for building (executing on the plan), while in software development you get more money for developing the solution (the design part). You just don't hear about multinational mega-corporations of architects on a level with FAANG.

Interestingly, the multinational mega-corporations handling ops do exist (PaaS, IaaS, app stores). They combine infrastructure, distribution and operations – in our comparison, in the civil engineering world they'd be an amalgam of builders, utilities and shipping companies all fused into one.

Cost of failure

If a bridge collapses, that's a huge problem, even if noone gets hurt. If software malfunctions, in most cases it's not a big deal (sometimes it is and then it's newsworthy). More often, if it works but badly, people scrape by.

Nowadays you can even fix the bug and push an over-the-air update – no need to recall all the cars of planes you've built with the defect.

This means the cost of failure (either catastrophic, or failure to live up to the expectations) is much lower in software than in either civil or mechanical engineering. That again means the return on investment (ROI) on any effort mitigating that cost is small, discouraging spending time and money on it.

So software today is buggy becase it can be. It's slow because it can be. It's insecure because it can be. It's not due to any lazyness of programmers, incompetence of managers or malice of big bosses. It's how the world works – if you spend too much on quality where not required, your competitor can spend the same money to grow faster with no downside.

Yet it is not obvious that it is unequivocally a bad thing. Consider the failures of famous projects with (near) unlimited budgets and perfectionism, such as Duke Nukem Forever. It makes as little sense to overengineer a software product as it would be for a building. Tech moves at breathtaking speed, and we've come so far in just a few decades, because it often can “move fast and break things”. Software can be more adaptable and quicker to the changing needs.

As software becomes a vital part of more and more things in the real world, the costs of failure rise. Whereas you might be only slightly annoyed at having to restart your Facebook app, you really don't want any trouble from the software controling your two-tonne car while you're doing 80 on a highway.

If that means more software will need to move slowly and avoid breaking things. And maybe we'll be more like the bridge builders.