Is software engineering really engineering? We’ve yet to hear a convincing argument to the contrary. In some respects, software engineering is more concrete than traditional disciplines.
What Do You Mean, “Real” Engineering?
One of the simplest illustrations of how software engineering differs from physical disciplines is the database. When I need a new property by which to relate entries, I can simply add it and re-sort data along this fresh axis.
When I’m designing a mechanical suspension, I can’t solve a problem by introducing new spatial dimensions with more convenient physical constants.
This is often as far as the argument goes: there is no physical product, software is a logical abstraction, therefore software engineering is not engineering. While it’s the most intuitively satisfying argument, physicality is actually the weakest ground on which to exclude software from the disciplines.
If a software engineer designs a networking protocol, and a civil engineer designs a bridge, what has each produced? We can’t give full credit to the civil engineer for the physical bridge; what they’ve produced is a meticulously abstracted representation of a bridge. This representation – design – is sufficiently rigorous that others can read it, generate tasks based on the engineer’s specifications, and manufacture a physical product with known properties. That’s the job, right?
Which engineer’s design is closer to their actual, realized product?
Giving priority to the civil engineer’s design as somehow more real – due to its non-negotiable physical and economic constraints, to be sure – is to magically equate the design of a bridge with the bridge. The civil engineer’s design output is documentation, tables of specifications, build-able plans and schematics.
The software engineer’s design output, on the other hand, is the actual bridge. Unlike the civil engineer, a software engineer can’t pass abstracted design to a compiler for building. The only specification of sufficient fidelity for implementation is finalized source code.
Yes, Software Engineering is Different
“Thinking of software creation as an engineering discipline has single-handedly been the most destructive model for the software industry, ever.” Gary Pedretti rejects the application of traditional processes to software engineering with a firmness I’ve come to associate with scarred veterans of the waterfall process.
The waterfall development model is decent for moving from design to physical creation. You work your way through layers of decreasing abstraction towards a physical product, with the goal of eliminating costly implementation errors as early in the process as possible. Each stage is a progressively more concrete design for subsequent stages, with testing the realized product last.
When building your ‘product’ is expensive and laborious, putting your sweat into those abstracted layers is perfectly sensible. Software engineering operates under very different material circumstances:
- Producing abstractions of source code is of limited utility to actual coding.
- The only specification detailed enough to implement is the source code itself.
- Implementing a product from source code is essentially free.
- Treating design, implementation, and testing as sharply delineated phases makes very little sense.
These ideas are neither mine, nor novel. They underlie much of current software engineering methodology, having spread far and wide from Jack W. Reeve’s 1992 musings on the subject:
If what we are really doing is software design, then everything we do will somehow be reflected in code. We might as well write the code (or that portion of it that makes sense) when we make the decisions that affect that code. […] Fundamentally, programming languages are just a design notation themselves. […]
Yet, traditional MIL-STD and other waterfall model development processes will not even allow writing one line of code until a certain tonnage of auxiliary documentation has been produced and reviewed. Often, the people who produce this documentation then go on to other things leaving a group of new, and usually much younger and less experienced people to actually generate the real software design. […]
Now we have rapid prototyping and spiral development. In my view, it is easy to see why these are replacing the waterfall method. Both of these are just excuses for writing code earlier in the development cycle so that the process of refining the design via build/test can begin sooner. They also typically get the same people involved in both the top level design and the actual code design. Not surprisingly, these two approaches are both seen as significant improvements.
“The fundamental difference is that software is effectively free to build, unlike physical things,” says Todd Shelton. This departure from the physical engineering disciplines has tremendous implications for how software is made and which processes are effective in project management.
Still, this line of argument seems less about software engineering as a discipline than it is that traditional, waterfall-style process doesn’t make sense when applied to software development. The relationship of design to product, the ease of implementation and testing, and the lack of a generalized design language for abstraction above the level of actual code do make software engineering an outlier among traditional engineering disciplines
Does project management structure dictate whether or not a discipline ‘counts’ as engineering? Tying the status of software engineering to workflow process or the form taken by its final design is specious, at best. It’s the fidelity and rigor of a design which determines success or failure, not how many binders of abstracted documentation are involved in its creation.
Try Engineering Without Software
Those in favor of software engineering as a real discipline have one killer argument going for them: technological civilization runs on software.
Airplanes know where to land and how fast. You read this on a powered device, thanks to real-time energy auctions and power grid management. The software engineering sector regularly cranks out mysteriously valuable ephemera, it’s true, but their work underlies and enables a lot of very real, very important applications.
“Software is frequently a critical component in systems where failure may cause catastrophic loss to human life,” says Kenny Katzgrau of Broadstreet Ads. Modern transportation, communications, and industrial processes are reliant on software and embedded systems engineering to function. “Any project managers who underestimate the role of proper software engineering in critical systems is asking for disaster.”
Another facet of this argument is how much of the modern STEM workspace depends on software engineers for analytical, design, and simulation tools. To deny software engineers a seat at the table after benefiting so tremendously from their work – and adopting so much of their process – seems a little ungrateful.
As our demand for smarter tools and products increases, so does the importance of rigorous software engineering. MbientLab‘s Laura Kassovic, whose team develops the MetaWare platform for connected devices, offers wearable devices as a prime example. “These consumer products incorporate mechanical elements, mobile app elements, firmware design and development, user research, graphics, and more; software engineers are an essential part of the product creation process and cannot be ignored or overlooked.”
If there is a killer argument out there which precludes software engineering taking its place among the ‘real’ engineering disciplines, I’m unaware of it. The output, required skill, and potential cost of failure in real world software engineering projects are all very real, indeed – in some respects, more so than the design output of traditional disciplines.
Maybe it’s time to shed this argument once and for all: software engineering is really engineering. If there’s a counter-argument that doesn’t privilege one class or method of abstraction over another, I’m willing to explore it with you over Twitter or in the comments.
Featured Image Credit: Adi Setiawan
All Images CC-BY-4.0