As Cal Newport has observed, the productivity of knowledge workers is notoriously hard to quantify. We want a nice clean metric. Number of paperclips produced, bugs squashed, bricks laid. Where the outputs are less clear – and less thing-like – measurement becomes… complicated.
That doesn’t stop some people from trying to make it seem easier. A particular business owner (who is much less clever than he thinks he is), for example, paid way over the odds for a large social media company and then, while trying to downsize his way to efficiency, weighed the value of his workforce by, more or less, counting their lines of code
Idiots and bullies aside, most of us are guilty of something similar. We wear watches that count our steps, we track our hours at work, we create tasks purely so that we can check them off as complete. We love to quantify and, preferably, we like to provide something relatively concrete as proof of our labour – whether it’s widgets, words or lines of code.
My team has recently been putting a lot of effort into refactoring a good but ancient PHP codebase. In another context, I’ve been editing. In both situations, the work often involves little production of new material. It’s a process of honing, and as such it can maintain or even reduce the volume of the source material under review. Blaise Pascal (or was it Mark Twain, or Cicero, or one of half a dozen others) wrote:
I have made this [letter] longer than usual because I have not had time to make it shorter.
And this is the problem. The task of making something shorter, does not come with a decent metric – apart from time, which is unreliable. It’s not enough to make your letter shorter. You also have to make it better.
Because we are so conditioned to metrics of productivity, there’s a guilt inherent to this. Writers post to Bluesky with their daily word counts. Dullard business owners demand code print outs. But both editing and refactoring are focussed on improving work that already exists. The fact that, if the task is done well, the product is immeasurably improved by this process is lost in the difficulty inherent in measuring the improvement.
In the case of refactoring, things are made worse by one aspect of best practice. That is, that you should only change one thing at a time. If you’re breaking down an overlong conditional clause you should not, at the same time, introduce a nifty addition to the featureset. The reason for this is simple enough. When something inevitably goes wrong after your changes are committed, it will be much harder to find the culprit if you’ve been making changes across more than one axis. So, if you’re sensible, you strictly only test and commit one improvement at a time. That means no new features and even, perverse as it can seem, preserving existing but unrelated bugs.
That you have created a safer environment for planned features and improvements can be a hard sell. On the whole, management are looking for measurable progress. New features to drive revenue or, at least, product marketing. The same only much better is not always received well.
This is made worse by the fact that the outcome of refactoring (in tandem with its cousin, improved testing) is often really only measurable with reference to a (likely imaginary) alternate universe – the subjunctive world in which all sorts of bad and expensive outcomes would have occurred had the code not been improved. Meanwhile in this, real, universe (the world in which I am writing this and you are reading it), the system did not fall over. In this universe, new coders are not introducing new bugs. In this universe, performance is not degrading. That may be true, but the imaginary universe in which the implied bad outcomes prevented by refactoring did occur cannot be shown to exist. You can’t prove a negative.
Much as we like to imagine a collegiate relationship between business owners and managers on the one hand and developers on the other, the reality is generally characterised by the exercise of power, which comes implicitly with a threat of sanction. As Foucault famously argued, one feature that makes modern power relations so enduring is the way that the less powerful are induced to police themselves.
And so we feel guilty. Even while we improve our code like ninjas in the night.
I wish I could conclude this article with a neat answer to the problem. The business is not wrong in looking for new features, after all. If we did nothing but improve a codebase, we’d not be offering enormous value. Like managers, end users won’t thank you for bad outcomes that did not come to pass if their feature requests are never fulfilled.
And so, I suppose it’s a matter of balance. To interleave new features with relatively stealthy improvements. In some workplaces this may mean a certain amount of deception (and therefore guilt). In the end, there’s sometimes nothing for it but to exercise bad faith in a good cause.
Photo by Patrick Tomasso on Unsplash
