more than features

2014-11-04

Externally, software is magic inside a computer that automates something humans can do, only faster. It is a collection of features that combine to do something useful. Users don't care how software actually works, only that it does. As programmers, we actually do care how the software works. We care about things like how easy it is to add new features or what kind of tests exist to verify behavior and stop us from shooting our own feet off when we refactor. This tension between internal and external is at the heart of programming.

It's easy to succumb to metrics and focus on those which don't matter. For example: using velocity as a metric of how well your development team is doing. Velocity is a terrible metric for measuring the productivity of your team. It's like ranking developers by how many lines of code they write or how good a meal is by how much food is on the plate. These examples are obviously ridiculous. All other things being equal, writing more lines of code is worse than writing fewer and the quantity of food has nothing to do with its quality. Yet somehow in the software world we use how many points we complete in a given time period to represent how well we're doing. This is a common mistake of confusing quality with quantity, or rather, believing they are somehow correlated or even interchangable with each other.

I believe the fundamental mistake being made is confusing software with other fields, such as construction or sales. When a job has an easily quantifable end result, such as bricks laid or cars sold, it's very simple to determine how good you are at your job. You lay more bricks, you're a better brick layer; You sell more cars, you're a better car salesman. These statements are correct because they measure tangible objects. If you want to get better at your job, your goal is to increase that number, that quantity of things you produce.

Software, on the other hand, is mind-work. It is pure imagination turned into reality by a computer. We build castles from clouds in our minds. Programming is intangible and therefore more difficult to directly measure. How you do you judge whether one piece of software is better than another? Lines of code? Bugs-per-KLOC? Churn? WTFs-per-minute? Readability? Maintainability? It seems that judging software quality is inherently subjective, like art. I believe we need to stop judging our progress like we're just cranking out widgets and fundamentally shift our thinking to judge ourselves and our work on more subjective axes, like the way we judge art, music, and other crafts.

How would you compare two pieces of music? Or paintings? Or hats? Is the one that's "bigger than bigger" better? How about a painting that uses lots of colors? Is such a painting superior to one that is a subtle interplay of light and shadow, depicting a man sitting by himself on a bench in the rain? Of course not! Nothing about the color(s) used in a paiting determines its worth.