(2021-01-18) Wayne Are We Really Engineers

Hillel Wayne: Are We Really Engineers? Mat, idly chatting... What’s your job?” Right now I’m working on microservices for a social media management platform.” “And before that?” “Geological engineering

Is software engineering “really” engineering?

On one hand you have the people who say we are not engineers because we do not live up to “engineering standards”.

On the other end of the horseshoe, we have people like Peter McBreen and Paul Graham who say that we are not engineers because engineering cannot apply to our domain. Engineers work on predictable projects with a lot of upfront planning and rigorous requirements.

For a long time I refused to call myself a software engineer and thought of other people with that title as poseurs

I realized something about everybody involved in all of these arguments. They’ve never built a bridge.

while “real” engineers could tell me what they did, they couldn’t tell me how their work differed from mine.

Only a person who’s done both software development and “real” engineering can truthfully speak to the differences between them.

I call these people crossovers

I interviewed 17 crossovers

I divided the write up into three parts, dealing with my three core topics. Part one is about the term “engineering”. Is what we do engineering, and can we honestly call ourselves engineers?

Why is this a Question?

“software engineering” is a real field. Most people would agree that the software running on spacecraft counts as “real engineering”. The debate is about the rest of the field. Are the people who build websites engineers?

Common Misconceptions

When I asked people to explicitly list the qualities of what makes something engineering, here are the most common responses

three claims to discuss here. All three are used to say software can’t be engineering. “We don’t use any math, unlike real engineers. Software doesn’t matter, unlike real engineers. We aren’t licensed, unlike real engineers.” As we’ll see, none of these quite hold up.

Engineering is mathematical

Much of the math that mechanical engineers use is continuous math.

In software, we don’t use these things, leading to the conception that we don’t use math. But we actually use discrete math: graph theory, logic, and combinatorics.

Engineering is high-consequence

Three months of the project dedicated to getting the handle working right.

Much of the engineering there is low-stakes, low-consequence, just like much software is.

«But there are still some things that lead to loss of life!» Yes, and the same is true of software. An integer overflow in the Intrado software lead to a several hour 911 outage for millions of people

Engineers are licensed

In Canada you can’t even call yourself a “Software Engineer” unless you’re accredited!

In the US, you don’t need a license to practice any kind of engineering. You need a license to be a “principal engineer”, a.k.a. the person who formally signs off on plans as valid. But the engineers working under the principal engineer don’t need to be accredited and often are not. In fact many of them don’t even have formal training as engineers.

licenses are a political and social construct, not a fact of nature.

The Truth

there aren’t any qualities we can point to and say “this is engineering, this is not”. It’s a standard Wittgenstein game problem: human constructs do not neatly fall into precise definitions

Once I realized this, my interviewing process changed a little. Instead of asking how they felt about certain engineering topics, I just asked them point blank. “Do you consider software engineering actually engineering?” Of the 17 crossovers I talked to, 15 said yes

That’s not the answer I expected going in.

Even the product owners and project managers are in a sense engineers […] everyone is kind of an engineer, an engineer of sorts. -Kate (chemical)

Craft vs Engineering

That said, many of the crossovers also added an additional qualification: software engineering is real engineering, but a lot of people who write software aren’t doing software engineering

Not everybody who works with electricity is going to be an electrical engineer; many will be electricians

we use things like “programmer”, “software engineer”, and “software developer” interchangeably

Some people propose the word “software craftsman”. This term comes from the book Software Craftsmanship: The New Imperative, by Peter McBreen

Many people have asked me why I care so much about this project.

if we are doing engineering, then we have a landmark

I believe everything McBreen said about software is fairly reasonable, about how hard it is to predict things and how it’s intensely personally created. What he gets wrong is the assumption that engineering is not this way.

I still believe that most of us are not engineers, because we’re working in domains that people don’t see as engineering. Most people don’t consider a website “engineered”. However, and this is a big however, there’s a much smaller gap between “software development” and “software engineering” than there is between “electrician” and “electrical engineer”,

We Are Not Special • Hillel Wayne

This is part two

Carl worked as a mechanical verification engineer: he tested oil rigs to see how much they vibrated

Currently, he was explaining how they find oil. After drilling a hole, he said, “you might also want to add other additives, like acid or hazelnut shells

By pumping in hazelnut shells they can gradually fill in small voids and test if they are still in the structure, gradually equalizing the pressure if they are.

According to Carl, oil companies are the biggest purchasers of hazelnut shells in Norway.

When people talk about the fundamental differences, in contrast, they’re usually not aiming to delegitimize software development. Rather, the implicit emphasis is on making software “special”. Making software something that can’t be understood by the narrow lens of engineering.

I see this as a defense mechanism. If software is so different from trad, then it’s okay for us to “not be engineers”. We can say that, sure, we aren’t planning upfront, but that’s because software requirements change so much faster than everywhere else. We don’t apply engineering because we shouldn’t be applying engineering.

There’s just one problem with this: as software engineers, we deeply misunderstand the nature of trad engineering. We are not special.

The claimed differences

Most arguments about engineering don’t go much beyond “software vs engineering”, or conflate “engineering” with civil engineering.

After a few interviews, I settled on a set of “universal” differences to discuss:

These aren’t all wrong. As we’ll see later, there are absolutely some differences between software and trad. But the majority of the differences are “wrong”, or at least lacking critical nuance.

Traditional is Waterfall, Software is Agile

While Waterfall was a dominant model for some time, it was never quite as strict as we think it was today. Nor was it all that ubiquitous: most developers in the 70s and 80s were either working with an ad hoc plan or working in one of the many, many, many “incremental” models that were in fashion, like the Spiral Model and the V Model.

But all that is tangential to the core claim: software engineering is Agile, while trad engineering is Waterfall. And this, unsurprisingly, is a significant oversimplification.

Even the most Waterfall form of engineering, civil engineering, gradually shifts to a more Agile-like process once construction starts. People need open communication and adaptation to deal with on-the-ground issues in building.

Why do we think software needs Agile and not Waterfall? Unpredictability.

“Software is More Unpredictable”

We don’t see the friction, the overruns, the delays that happen because someone built the wall one inch to the left, or when a critical supplier goes out of business

One person talked about how frustrating it is to start work on a bridge foundation, only to find that this particular soil freezes in a weird way that makes it liquefy too much in an earthquake. Back to the drawing board.

“The Code is the Design”

Design and construction aren’t nearly as disjoint as we software engineers think.

The constructed product might show issues in the design, or it might show issues in the circumstances of construction. Mike, one mechanical engineer, called it “fettling”. Tweaking the design to deal with the slight imperfections of the construction process

Rigor

First of all, any less rigor we have isn’t entirely cultural, because the essential nature of software makes it a viable tradeoff.

Software lets us gather empirical information more easily, which itself is a source of rigour.

You can always add more brackets. -Carl

The Real Differences

Consistency

By contrast, let’s look at physical materials. In electrical engineering, a core component is the resistor

Note the last band, though: that specifies the tolerance

And this is to say nothing about wear and tear, or how resistance varies with temperature, etc.

Velocity (iterative)

We can change software much faster than anybody else can change their systems

why other engineering fields are progressively using more software by creating these design tools and simulations, engineers can prototype their ideas with software before implementing them.

There is also a darker side to this. Because software can iterate faster than trad, trad often relies on software to compensate for problems in physical equipment.

In 2019 over 300 people died in two 737 MAX airplane crashes. Boeing only added MCAS in the first place to compensate for late-discovered issues with the plane’s aerodynamic profile. Rather than fix a trad issue with trad engineering, Boeing opted for the software kludge, and then people died.

Constraints

constraints in software tend to be soft constraints. It is bad to go over them and the more we go over the worse it gets. We can slightly fudge the line if doing so will give us other benefits, like faster development time or simpler algorithms. In traditional engineering, most constraints are hard constraints.

software engineers can undo their kludges. Trad engineers cannot.

Do the differences make us special?

Every field of engineering has unique challenges and software is no different. But they are all much more similar than they are different.

it’s a good thing that software isn’t special. It means that we can learn a lot on how to make software better from these other fields. And it means that they have a lot to learn from us. Because surprisingly, there are some ways that we are better at engineering than traditional engineers.

What engineering can teach (and learn from) us • Hillel Wayne

I met William at Deconstruct 2019.

He knew about my project and wanted to share his memories of mechanical engineering.

“Most of my skills transferred seamlessly. There’s one book, Sketching User Experiences, that’s aimed at software engineers. But it was really influential on me when I did mechanics. Up until then all the books I read were things like The First Snap-Fit Handbook: a lot about the how but very little about the why. And that’s important! But this book on user experience, though, it helped me a lot.”

Something struck me. “That book you mentioned on snap-fits, you said it was also useful. What’s the equivalent software book?” He thought about that. “You know, I can’t think of any.”

This essay is on the future state: how, by accepting its place in the engineering field, we can aim to improve it

I’m a firm believer in the potential of interdisciplinary research, that we as software engineers can learn valuable lessons from librarians, social workers, and zookeepers. I expected the crossovers would have lots of valuable advice here.

I wasn’t expecting it to go the other way, too

What we can learn from them

The most common answers I heard fell into two broad categories: 1) we can prepare more, and 2) we can care more.

More Methodical Processes

Of course, there’s technical reasons why we don’t need to plan as much as trad engineers do. In software, we can iterate much faster

The problem is just that we’ve gone too far the other way.

And what is “upfront planning”, anyway?

The ultimate impression I got was what mattered most was time. First and foremost, there was not enough time between project conception and the first lines of implementation. Crossovers wanted more time to think about things before they did things. Just a couple of days of planning would make a big difference, regardless of how people used that time.

engineers thinking about a lot of “Where is this thing gonna fail? What is gonna go wrong?”

The usual response to this is that software is inherently unknowable, so we cannot plan like engineers do. As discussed in the previous essay, this underestimates just how uncertain and unpredictable trad engineering is.

The response to plans being imperfect is to make flexible dynamic plans, not to throw away planning entirely

Most trad engineering is physical, while most software is intangible. That makes it harder to feel responsible for its impact

We can all agree our culture could be better but not know how to get there.

And What They Can Learn from us

Everybody listed the same two things that software does especially well, often in great detail. These are open communities and version control.

Openness (hacker ethic)

We software engineers take the existence of nonacademic, noncorporate conferences for granted. But we’re unique here. In most fields of engineering, there are only two kinds of conferences: academic conferences and vendor trade shows.

In addition to helping us improve our skills, software conferences also break down silos in software.

hampers how much other fields can open up. Trad engineers could share more material online and run more practitioner conferences, but atomic spectrometers are never going to become commodity products

Version Control

Version control is the single most innovative, most revolutionary, most paradigm-shifting tool that is uniquely ours.

Part of this is our preference for plaintext source code. Our VCS tools aren’t nearly as suited for things like diagrams and spreadsheets, which are more common in trad fields. But that doesn’t preclude version control on other formats: after all, GitHub can diff CAD files. And many engineering artifacts are also written in plaintext. A requisition form or an SVG diagram can easily be version controlled in git.

On top of this, our tooling surrounding version control is extraordinary

There’s so, so much more we can learn by talking to crossovers. And I encourage you to do so! I learned more in the first two hours of interviewing than I had than from all the thought leader essays on the subject.

To summarize my ultimate conclusions

First of all, We software engineers are “really” engineers. All the differences people give between software and “real” engineering don’t accurately reflect what “real” engineering looks like

At the same time, there is a difference between the different ways people make software, and it makes sense to think of software developers and software engineers as distinct concepts

Second, we are not special

The same ideas that engineers use to advance their craft are equally useful in our own domain.

Finally, there is a lot we can both teach and learn.