Productivity

You can't measure it, but you can manage it.

How do you measure productivity? Let’s start by talking about the engineering obsession with quantitative metrics. You can easily measure productivity on an assembly line. The faster a car comes off the line at a given quality level, the more productive you are. We do not work on an assembly line, however. We are not producing identical copies of the same object over and over again. No assembly-line productivity metric can be applied to software development.

Deming once said, “You can measure only 3% of what matters,” and this is one of those cases. All the “productivity” metrics I see measure output. You are not productive if you produce vast amounts of garbage quickly (PRs/unit time come to mind). Even “_value_ delivered over time” isn’t measurable, because you can’t measure value. Productivity matters. You can’t measure it, however.

Sometimes, a group of metrics taken together can help. The DORA metrics (deployment frequency, lead time, change-failure rate, and mean time to restore) taken together come to mind. None of these, in isolation, does anything useful. A team with a high deployment rate is productive only if it also has a low failure rate, etc. It’s all or nothing.

But even taken together, DORA metrics are not sufficient because they’re still output measures. Take lead time: the time from when a problem is identified to when the solution generates revenue. (Idea to the customer’s hands.) Some problems are just harder than others, so they take longer to solve. That extra time doesn’t mean you’re less productive, however. A simple lead-time comparison tells you nothing useful.

People talk about how AI assistance makes them more productive, but that’s particularly fraught because the “out of the box” code always needs to be inspected and refactored. People who check in unreviewed code are actually anti-productive because someone down the line will have to deal with the problems in that code. AI-generated code is also overcomplex, and if somebody doesn’t deal with that complexity, it will kill you down the line. I’m not saying that using AI is not a good thing. It does make people more productive. Just not in an easily measured way, and only if the programmers approach the generated code with scepticism.

Deming also said, “It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.” You can’t measure productivity, but you _can_ manage it. The best indicator I can think of is how long it takes to make a necessary change and how solid that change is (solid code stands up over time). “Solid” applies to everything from code quality to whether your solution to a customer problem is a good one.

When the change time is low, productivity is high. If the code isn’t solid, the constant fiddling with it lowers my productivity. We’ve all experienced code that’s hellish to work on, where a change that should take a few hours takes weeks. When I work in code like that, I’m not productive (and very unhappy). This is a relative measure. Some things—some changes—are just inherently difficult, so take longer than others.

So, even if I can’t measure my productivity, I can manage it by looking for things that slow down change and eliminating those things. There are many specific things that slow me down. Wrestling with bugs. Dealing with unnecessary complexity. Inappropriate or bad architecture. Bad overall code structure. Unhelpful names. Low quality in general. Code that doesn’t make what it does obvious when reading it. The list goes on. By dealing with those things, we become more productive. If you want to measure something, measure how many of those issues you address.

A Buddhist monk (yes, seriously) once told me that suffering is the distance between the way things are and the way we think they should be. Productivity works the same way. The smaller the gap, the more productive we are. Productivity is a relative delta, not a hard number. Narrowing that gap reduces our suffering 😄.