Continuous delivery: Software craftsmanship is not enough

Here's a secret about software development: what many developers think of as "software engineering" isn't engineering at all. However, when you apply real engineering principles, these revolutionize the speed, efficiency, and quality of the software development process, and of the software that you produce.

It's time to define the term software engineering, and to adopt the disciplines that go with those definitions.

I have been fortunate to have worked with world-class software developers over the course of my career. I held various job titles, often with the word engineer in them (though in recent years, in the places where I worked, those titles went a bit out of fashion). Even in these excellent teams, were we really engineers? For the most part, no!

The term software engineer has become a bit discredited in some circles. Certainly, some proponents of agile approaches to development began to prefer the term craftsman to engineer.

I think that there are some good reasons for that. Here's more of my thinking on this issue.

How to Build a DevOps Toolchain That Scales

Software development requires creativity

Software development is an intensively creative discipline, though developers don't always think of it in those terms. All developers create new solutions to solve problems. If they aren't doing this, then what is the point? After all, if developers weren't creative, then you could write a program to replace them.

There is a difference between being creative and being original. I don't mean to imply that every developer is breaking new ground with every line of code. Rather, in the same way that I, as a writer, may reuse similar sentence structures and word patterns in my writing, as a developer, I may do similar things with code. The sum of the parts is something new, at least new to me as a writer of this text or as a developer in the context of my codebase.

[ Special Coverage: All in on All Day DevOps ]

Software development is about craftsmanship

The idea of craftsmanship appears to align with this creative aspect of software development a little better than engineering. That, though, is a mistake. Engineering, too, is a creative discipline. Too often when people talk about engineering, they confuse "production" with "engineering."

That is because for people creating physical things, production is a tricky problem. For us software developers, production is easy (or should be). Production is what happens when we run our compiler or call our build system or, these days, commit a change to our continuous integration environment. For us, "production" is a solved and relatively simple problem (or should be).

Engineering is not only about production, though. The people who design planes or trains or bridges or production plants are also engineers. Engineering is a disciplined, but creative, endeavor. The act of production is not really the engineering part; the design, the creation, the solving of problems is where engineering really lives.

What is engineering?

I think of engineering as this: "Engineering is the application of an empirical, scientific approach to finding efficient solutions to practical problems."

This is a broad definition, but there are some subtleties here.

  • It is empirical; we need to measure things and react to what we learn and adapt based on the ways in which our discoveries change our understanding.
  • It is based on a scientific, rational approach to problem-solving. We need to carry out experiments, try out ideas, and discard the ones that don't work. 
  • The solutions that we find need to be efficient, not just in terms of performance, but also in terms of being cost-effective.

So I have a question for you. Would you prefer to fly in an airplane built (designed) by craftsmen or by engineers?

I will take the engineered airplane every time.

Craftsmanship vs. engineering

It takes craftsmanship to do good engineering, but craft alone is not sufficient. Craft-built things are always, despite our sometimes romantic view of them, lower quality than the products of an engineered approach. Imagine for a moment the absurdity of a handcrafted iPhone. We leverage our capabilities, our quality, our productivity through engineering.

I think that the adoption of "craftsman" rather than "engineer" as a description of our profession is understandable. It was a reaction against some of the outrages performed in the name of engineering in some parts of our industry. Big-up-front designs of horrible, over-engineered systems. High-ceremony development processes that brought software development to a halt in many organizations.

But don't confuse bad engineering with engineering.

Leverage software development through engineering

Of the great software developers that I have worked with, some really talented developers (non-engineers) produced less and lower-quality work than less gifted people applying more engineering discipline. We need to gain the leverage that engineering offers to create a world-class result.

So what is software engineering? I think that a good starting definition involves these principles of software engineering:

  • It's iterative
  • It employs feedback
  • It's incremental
  • It's experimental
  • It's empirical

Continuous delivery is an engineering discipline

I believe that my preferred approach to software development, continuous delivery (CD), is a genuine engineering discipline.

Organizations that practice CD see dramatic improvements in quality and productivity. This is because it is a disciplined development approach, grounded in the five software engineering principles listed above.

We work quickly and iteratively to refine our systems and our understanding. We actively build systems called "deployment pipelines" to establish efficient, high-quality feedback. We build systems in steps and release them frequently so we can observe what works for our users and what doesn't. And we use high levels of test automation, via test-driven development, to carry out tens of thousands of fast, efficient experiments on our code. These experiments help guide our designs toward higher-quality software. 

Software developers: You're responsible

The recent court case of a Volkswagen software developer who was sentenced to 40 months in prison for falsifying emission results is an important event in the history of our industry. 

Software developers are now shown to be legally responsible for the decisions that they make and encode in their software. There is no "It wasn't me, it was in the requirements" defense.

Software is important stuff—the most disruptive force in our civilization at the moment. We software developers are creating the stuff that is changing the world.

I think that we need to retake the term software engineer and reframe it to mean something concrete and specific. This is not an analogy: We should not be like engineers; we should be engineers. Engineering requires knowledge, discipline, and structure.

You don't get to be an aerospace engineer without understanding aerodynamics. You don't get to be a chemical engineer without understanding chemistry. You don't get to reinvent the laws of physics every time you build a new bridge. Software engineers need disciplines of their own.

Establish an engineering mindset

I believe that our industry needs to take the next step on our journey. We have discovered techniques that work. We have data that shows that these techniques work better than other approaches. If we don't take this step at some point, a software disaster will happen on a bigger scale than the VW emissions scandal, and legislation will take over.

Let us take this into our own hands. We are the experts. Let us create a discipline of genuine software engineering and create better software, faster. And maybe along the way we will adopt a stronger sense of professional ethics to complement our more disciplined approach.

It is time to take back the term software engineering. Craftsmanship is not enough.

To learn more, don't miss my live presentation, "Taking back software engineering," at the All Day DevOps online conference. Registration is free for the 24-hour event, and you can also watch my talk, or any of 100 others, on YouTube after the event concludes.

Topics: DevOps