Software Engineers Are Not Code Machines

There is a disturbing trend in software, and that is the belief of some managers that software engineers are machines that punch out code. For them, the world is defined in terms of metrics, a focus on predictability, and very frequently, a rush to outsource engineering to countries with the lowest possible hourly rate.

If you were actually working with machines rather than people, you'd probably use the same metrics. In fact, because you were working with machines, you'd probably have fewer metrics! You wouldn't need them as much, because, well, machines are 100% predictable except when they break down.

But software engineers aren't machines. They aren't even process workers running an assembly line, despite what many other CTOs and engineering managers might like to believe. The best ones are artists and craftsmen first. And because software engineering is still as much art as science, that isn't going to be changing in the next few years at least.

The difference between a process worker (or a machine) and a craftsman, besides the level of skill required, is the amount of love they put into what they create.

A few things follow from this.

• Their code is personal and must be the best it is possible to do. If I were to buy a sofa from a big box retailer directly from an assembly line, and it broke, I'd call a support number and hope for the best. But if I buy a custom piece from a craftsman, I'm pretty sure I'm only going to want the original craftsman or someone who works with them to fix it for me. And they will love fixing it because they made it. So too with software engineers.
• Craftsmen don't need blueprints and plans that go down to the lowest possible of detail because they know their craft. If you are too prescriptive, you don't get the benefit of their skills and experience. So it's better to say what you want, but not how to get it. Software architects take note: if you are working with craftsman, you should prescribe only what you must, and not a thing more. Let your people amaze you, and trust that they will.
• Metrics are useful. But they need to recognize software engineering is not a process of putting screws in holes in an optimum manner. Find metrics that recognize the inherent uncertainty of a craft which nonetheless measure progress in a useful way. Instead of lines of code or defect counts, think of measures that show progress to a goal. Point velocity in agile is a somewhat imperfect example of a metric that goes some way to doing this.
• Software engineers treated as process workers churn out of organizations because they are seen as highly replaceable, which becomes a self-fulfilling prophecy. Software engineers who are craftsmen do not churn because they are valuable and have unique talents that are respected and cherished.

When I talk this way to engineers, I've never once had a negative response. On the other hand, when I talk to managers who are responsible for engineers, they are much more cautious. They know it is hard to manage to artists and craftsmen, and want people that just produce on demand.

That's understandable. But also unrealistic.

It is time to end the idea we can treat software engineers like machines that produce code when you shove in a user story or requirement. We've been trying it for a couple of decades now, and it isn't working.

What is working is letting the talent use its talent.

Let us put the human back into our craft. Every piece of software is a unique artifact that's the result of considered decisions made by skilled artisans. Let us celebrate this, and applaud the process of creativity that results in great software that people love.