Put the engineering back in software engineering

A not-so-simple question

Dear software makers,

What are we?

Are we hackers, who, in the words of Richard Stallman, explore “the limits of what is possible, in a spirit of playful cleverness?”

Are we craftsmen, who, in the words of the Software Craftsmanship Manifesto, “are raising the bar of professional software development by practicing it and helping others learn the craft?”

Are we ninjas, jedis, gurus, or rock stars?

Stereotypes and Caricatures

Personally, I wouldn’t want any of these titles, and I’m troubled that anyone would want to glamorize what we do with terms like rock star. I certainly don’t see anyone here where I work wearing leather pants and thrusting their hips toward a screaming audience (nor would I want to!).

I’m somewhat fond of a caricature I grew up with, which was something like a pedantic, bearded, and pony-tailed dungeon master, similar to Comic Book Guy in The Simpsons — but that’s not something I see around either. It’s a stereotype, probably an old one, and it probably never reflected the truth.

What exactly, then, defines those who make software?

Doing Rather Than Being

My experience is that the most defining characteristic of software creators is that we’re doers who want to solve real problems. Why create a wrench when there’s no bolt to turn? Why assemble the bolts and brackets and other parts, if the result doesn’t make life better for someone?

A practical outcome, that’s what we’re after.

Every day that I go to work, I want to write code that has a result. It could be calculating a statistic, delivering a message, booking a trip, paying a bill, or any one of a million things. But the essence of building software —the purpose, the motivation, the heart of it—is in the end goal. Without a final outcome, the activity of making software would cease to have any meaning. It would be the most dissatisfying experience in the world.

What if we’re “engineers?”

Now, in my opinion, that’s the definition of an engineer. Henry Petroski, a professor of civil engineering at Duke University, has said, “science is about knowing, engineering is about doing.” What better description could there be of the heart and blood pumping through the software engineer than that?

Doers are engineers.

Science is about knowing, engineering is about doing. ~Henry Petroski

Engineers are doers, with a caveat

Engineers are doers, but with an important distinction. We’re not designers and we’re not mad scientists. We’re not, for example, the crackpot scientist Doc Brown from Back to the Future who is always running around imperiling space-time.

As fun as Doc Brown is to watch, we wouldn’t want to be known as dangerous people.

But, to get real world results from software, we do have to know something about the real world and that’s also embedded in the idea of engineering. Often, what we need to know to accomplish some task is knowledge that’s already available, if it would only be applied.

In other words, the fastest and best way to achieve a result is to take what’s there and put it in action.

How it all goes wrong

The flip side is also true. Disregarding existing knowledge often results in disaster. A building constructed without sound engineering practices collapses to the ground.

So as we work on the problems in front of us, we likely have a dozen real-world considerations flooding in at any moment, threatening to derail our efforts. Our only comfort will be that we’re aware of them and mitigate their impact.

Take a normal, everyday business example: crunching some statistics for the visits to a website over the day‘s “peak hours” of 5am to 7pm. To even select the right data in the first place, we have to have knowledge of which time zone (UTC) and time format (ISO-8601) the database uses.

Even then, our effort may be thwarted entirely by a simple oversight. Although the times in the database are in UTC, “peak hours” happen in pacific time, which means they vary depending on whether its daylight savings time or not. When pacific daylight time is in observation, peak hours fall across one range in UTC (12pm to 2am) and across another (1pm to 3am) when pacific standard time is in observation. We’d need to take into account which time zone is actually in effect for the day in question, if we want to be correct.

Knowing the body of knowledge that’s been gathered about the real world and then applying it through software, is therefore key to doing anything with software. This is why I have one burning message for programmers right now:

Put the engineering back in software engineering

What I mean is: become familiar with any science or mathematics that impacts your particular software domain. Not just computer science! Know any relevant statistics, physics, biology, meteorology, chemistry, geology, or psychology. Keep references near at hand. Make no assumptions and don’t pioneer your own path where good paths already exist.

Know and follow standards. Seek out the tried and the true. The physicist and mathematician Freeman Dyson once said,

A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible.

These two guiding principles: knowing accepted science and applying already-existing, stable solutions wherever possible, will allow us to do more good for the world.