Software Engineering is Engineering

There's a debate about whether or not software engineering is "really" engineering. I want to put a stake in the ground and state my opinion: software is an engineering discipline, and software engineering is engineering.

I think a large part of the disagreement on this topic is that people actually disagree on what "engineering" means. I'm taking my definition of engineering from Dave Farley's book Modern Software Engineering:

"Engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems."

--- Dave Farley, Modern Software Engineering

I'm going to start this article by summarising the arguments on why software engineering is engineering made by two other authors: Dave Farley and Hillel Wayne. Then I'll conclude by saying why I feel the terminology matters.

Dave Farley's book Modern Software Engineering is about the core practices that Dave considers to be part of an engineering approach to software development. Naturally, this comes along with the assertion that software is indeed an engineering discipline.

One of the interesting distinctions made in this book is between "production engineering" and "design engineering". Most other engineering disciplines can be thought of in two sections: designing the first thing, and then scaling up the production and distribution of many copies of the thing. Designing one car would be fall under the category of design engineering, but car companies don't sell one car. They engineer production lines to create many of the same cars and get them to customers. Software engineering is interesting in that many of the production challenges, like scaling from one copy of a program to many copies of a program, are basically free. We can focus almost entirely on the design engineering aspect.

This also explains the bad reputation that the term "software engineering" has. There are many engineering practices which make a lot of sense when you need to prepare for production engineering, which are disasterous when applied to software. Processes like waterfall are production engineering techniques, and don't make much sense for software.

Regardless, the majority of Dave Farley's argument for why software is an engineering discipline comes down to engineering being the most appropriate umbrella term for the things he wants to write about in his book. Engineering practices are the things that we've collectively found to work well to build things, and he wants to talk about the things that he's found to work well when writing software.

In other disciplines, engineering simply means the "stuff that works."

--- Dave Farley, Modern Software Engineering

This book's foundation of what it means to take an engineering approach is broken down into two broad themes: learning and managing complexity.

• Learning is important because we're usually building something new in software. If we're tackling a well known problem, we'd usually just copy and paste the existing well known solution. In this context, learning means doing things like getting your software into the hands of real users who can give feedback as soon as possible, working in small deployable pieces, and writing tests to verify your designs.

• Managing complexity is important because otherwise it limits how the system can grow and evolve to meet the needs that we learn about. It's important to remember that, since engineering is a human activity, this also means managing the complexity of the human systems producing the software. Modularity and separation of concerns is important in code, but as engineering organizations scale it's also important in teams.

If you'd like to hear more of Dave Farley's opinions on software engineering, you can check out his Youtube channel, Continuous Delievery.

Hillel Wayne wanted to figure out if software engineering is really engineering, so he undertook a research project. He called this the Crossover Project since his methodology was to interview people who have worked professionally as both "traditional" engineers and as software engineers, since they would have the best insights into both what engineering actually is and how writing software works. Hillel's articles are well researched and well written, so if you're interested in digging deeper I would recommend reading the full series of articles on his website.

That's when I realized something about everybody involved in all of these arguments.

They've never built a bridge.

--- Hillel Wayne, Are We Really Engineers?

To summarise his findings, there are large differences between the different schools of traditional engineering that make it difficult to define what exactly "engineering" is. Civil engineering looks different from chemical engineering. This leads him to the tautological definition that engineering is what engineers do. When the crossovers who had worked both in software and traditional engineering fields were asked if they consider software engineering to actually be engineering, the majority said yes. Therefore software engineering is engineering.

For the software engineers who don't know much about traditional engineering, this can be surprising because they don't expect traditional engineering to be as unpredictable and creative as it is. Traditional engineers also work on designs iteratively, and also discover unexpected things late in the process which need to be worked around. Sometimes, you do need to move a bridge.

For traditional engineers who don't know much about software engineering, this can be surprising because software engineers don't seem to spend as much time doing math to think about how our system might act. This is one of the areas that software is different from physical space: it's economically very cheap in software to construct a thousand copies of the thing you want to test and knock them over. I'm sure civil engineers would love to build a thousand bridges and drive increasingly heavy trucks over them to see how much weight they can take, but that would be prohibitively expensive in their medium.

Ultimately, I would like a stable term for building software in a way that, to the best of our current understanding, is an effective and economical methodology for building software.

Software engineering was maybe a good term for this once, but over time people have come to associate that with the practices we tried under the software engineering banner which didn't work, like waterfall. When I started working professionally, the term "agile methodology" was used to refer to the things that worked. More recently, I feel that "agile methodology" is starting to become associated with processes that don't work, like Scrum or SAFe. I wouldn't be surprised if a few years from now we have some other term that we use for the stuff that works, and think poorly of all agile methodologies.

When I refer to software engineering, or taking an engineering approach, I don't mean any particular practice. I mean taking the approach which empirically works well for the situation at hand to build software. For most of my day to day work, I think that most of the practices from Extreme Programming are the correct engineering approach. For large open source projects primarily driven by volunteers in their spare time, this is probably not the correct engineering approach.

There are also a few areas that the traditional engineerings fields have a head start that I think we should be considering. Namely, how to train new engineers and certification.

I studied electrical engineering at university. It's a four year professional degree program which includes a variety of skills which form a basis for joining the workforce as an electrical engineer. This means some maths (usually "maths for engineers" courses which skip over the proofs and focus on using the results), physics (also "physics for engineers"), and a lot of electronics. On top of that, there's a bunch of other supplementary skills, like writing, some project management, a bit of economics, and a small amount of sociology.

I only had a handful of software courses, but overall my degree still prepared me well to enter the working world as a software engineer. It would have prepared me better if I did less electro-magnetic mechanics, and did more data structures and algorithms.

I don't know of an equivalent university degree program that prepares students for software engineering in quite the same way that we have degree programs for electrical engineering. Many people aiming to become software engineers go through computer science. Even though they come out of university able to program well, they don't know fundamental skills for working in a software company like using version control systems.

We could take the same structure we use to train other engineers as a model. There are some common parts that all engineering students need to learn, like economics, and others that are more specific to software. The chemical engineers need more chemistry courses. The mechanical engineers need more mechanics courses. The software engineers need more computer science. But, crucially, the focus isn't on learning computer science for the sake of computer science. It should be "computer science for engineers", which skips over the proofs and focuses on using the results to build things.

For some, certification is a beaurocratic red flag. However, right now, it seems a bit strange to me that we don't have any certification requirements at all.

Software has reached the point where it can have a massive impact on public safety. I think that the software that runs medical aids and large financial institutions should be signed off by a certified engineer to watch out for public safety.

However, I wouldn't push for those sorts of regulations today, because we're still missing a rather crucial prerequisite: what cerification would actually indicate that someone can build a safe system? It seems to me that we need a standard way to train software engineers that we can definitively say makes them write safer software before we can have regulations to insist that a software engineer should go through the process.

I believe that software is an engineering discipline, and I'll continue to call myself a software engineer. This is partly tautological: I feel that "engineering" is the most appropriate word for the type of software writing practice that I aim for.

I feel it's important to use the term software engineering because, firstly, it's useful to have a stable term that refers to the current best practice in building software economically. Secondly, it's useful to use the term software engineering because it reminds us that there are many useful things we can learn from other schools of engineering. Even if we need to consider critically which lessons actually work in the incorporeal medium of software.