Recently one of my teams wanted to evaluate a programming technique on the axis of legibility versus performance.

The initial instinct which struck me, was to back away from such a muddled and tenuous topic. This being the aggregated result of numerous discussions and debates about technologies and personal preferences, things with no clear cut answers, yet developers insist on debating, wildly and openly. Rivalries are created, wounds left open, relationships shattered. Like, real tragic stuff. Elizabethan even.

Still the concept refused to leave me. I’ve been embracing this idea that so much stuff at work which makes me upset, things would could be categorized as an asymmetry of caring, could just be left alone. To quote a friend and former co-worker, when it comes to so many of these things: “You could just not”.

I could just not entertain the idea and the proposed discussion. I could remain mum if it actually happens. I DO have the right to remain silent (right?), especially when it comes to engaging a topic that could turn me into a maniac. All that requires is some degree of patience, and maybe a pinch of denial.

But still.

In Programming Pearls, Jon Bently notes “The context[…] defines the performance requirements”. It makes sense to reframe this conversation: It’s not a tradeoff of legibility versus performance, and even if it was, it would STILL require context to be sanely debatable – it becomes a question of not having team rules or values. Do we favor performance more, or do we favor legibility?

I generally abide by the rule of “make it work, then make it fast”, and for me, writing legibly tends to fall under the scope of making it work. Writing and naming comes to me more naturally than analysis, for which I require targets, tools, and measurements.

The true clarifier, is knowing we are working on legibility versus performance over time. If we apply the heuristic of “make it work, then make it fast” over the scale of time, we start to see that the greater context matters. We are part of a business which is relying upon our ability to ship features, and yes, performance itself can be a feature. The context of time and the priority of other initiatives will dictate just how much effort we can put into performance tuning when it requires analysis and overhead.

Using axis of time gives us a fairer framing of the discussion: what are we going to do with our limited time?

I love having the space to figure out how to make something work slightly better. Where legibility is more self-evident, performance requires some degree of measurement and boundary setting. It is not often, in my experience, that business allows the extra space required to apply performance upgrades. With the time consideration, we can at least make a sane argument for how long we are willing to spend on it and what we are willing to forgo in order to achieve better performance.