Skip to Content

Is Software Engineering Real Engineering?

Description: What makes software engineering different from “traditional” engineering? To find out, I interviewed 17 “crossovers”: people who have worked professionally as both a software and a traditional engineer. In aggregate, we learn three things: we are in fact engineers, we’re not actually that different as a field, and there’s a lot we can both teach and learn.

Slides are here. Video is here.


These are some of the questions I remember people asking me after the talk. I’ll also put up questions emailed too.

Why does it even matter if we’re engineers or not? Why can’t we just be software developers?

Two reasons. First, lots of people do have strong opinions on the “engineering” question and use it to make strong value judgements on software as a field. I can’t tell people to stop caring about this question, but I can try to make sure that if they compare “software” to “engineering”, they don’t have misconceptions about what “engineering” is.

Second, I deeply, deeply believe in the value of interdisciplinary dialogue. If software is like engineering, then we can learn a lot about software by studying engineering. Like, a lot of devs talk about how incredibly unpredictable software projects are, but every engineer I talked to said the same thing was true about their old jobs. So how do they deal with unpredictability? Is it anything we could do, too?

Did you talk to people about job satisfaction?

A little. Most of the people strongly preferred their jobs in software than their old jobs in classical engineering.

Did you talk about meetings?

I did not. There’s still a lot to learn about software and trad engineering!

Why didn’t you talk to biomedical/audio/environmental/etc engineers?

While I think there’s insights to learn from these people, too, I wanted to define “engineering” as conservatively as possible. I was worried that if I used a more liberal definition, software folk would be more skeptical of what I learned. By sticking to “stereotypical” engineering fields I can avoid that specific objection.

Why do other fields think software is “easy”?

Every field seems easy until you actually get into it.

Waterfall was originally agile from the start.

Winston Royce originally introduced “Waterfall” in Managing The Development of Large Software Systems. It’s a common misconception that he was originally rejecting waterfall and advocating something more Agile-like. However, a close reading of the paper shows that while he recommends some changes to the basic waterfall approach, they remain highly waterfall and his result is still “highly waterfall” him support waterfall and most of his recommendations are to keep in the waterfall style. See Leprechauns of Software Engineering for a more in-depth discussion.

Isn’t it too early to start collecting information about software “snapfits”? How do we know current solutions to EX plugin systems aren’t all fundamentally flawed?

I discuss this question in depth in this essay.

So what is the most important videogame ever made?

Space Traveler.


Certification regulations