Why devs hate maintaining code

I got 99 repos but I finish none

Software developers are creators by our very nature. It is perhaps that personality quirk that drew us to this work in the first place. We have such a compelling need to create that we tend to find ourselves building things halfway and moving on to the next one. Heck, you’d be lucky if it even reached halfway. We often have a couple or so perpetually ongoing projects at any given moment.

This is by no means a bad thing. I am merely pointing out the nature of software developers and our need to have our creative itches scratched. And also we have an excuse, software is never truly finished. (Or was that art?)

Maintaining software

But life rarely gives us what we want. Working as professional developers, we almost never get the chance to write anything from scratch. We join a company and get asked to wrangle code of an already existing software serving the company’s customers and bringing its revenue.

But when the stars align, we do get a chance to write code from scratch. And when this happens, it feels like winning the lottery. These slivers of joy and excitement in our careers will be very few. Because for the majority of it, we have to deal with old, decrepit hand-me-down software from a long line of developers that probably left the company to join the hippest new startup in the next block.

These “legacy” software, as they are lovingly called by corporate management is so dreadful to maintain that I have seen many developers just throw our hands up in the air in surrender asking management to allow them to just rewrite it. To which management often says “no” and the developers grumble a bit but continue maintaining the code anyway.

But why? Why do so many developers wish we can just rewrite the whole goddamn thing? (Even if at times, it’s completely a pipe dream.)

The Jenga Tower

Software development is like a game of Jenga. In case you are not familiar, Jenga is a game where players take turn removing one block at a time and placing it on top. After many turns, the tower will be so unstable that whoever causes it to collapse loses.

Everytime a feature is added to the software, it is added metaphorically to the top of the stack. It adds weight to the whole structure. There comes a point when the tower is so unstable that a tiny modification the software makes it collapse.

This is called Software Brittleness.

Brittle software behaves much like a real-world brittle material. It cracks and raptures with smallest application of force. This is because it has reached its elastic limit. Software also has inherent elastic limit. However, I still wonder if there is a way to quantify that.

But brittleness doesn’t set in by itself. It is introduced by the developers themselves. Brittleness is created everytime a shortcut is made.

The speed of which the brittleness sets in is a function of the number of shortcuts made. Shortcuts are not free. You get speed but you pay for it through future maintainability.

The holes in the Jenga tower are the shortcuts from the previous development. Of course you can always use all three blocks for every layer, that would keep the tower from falling as it rises. But with unrelenting pressure to deliver coupled with lack of knowledge in the domain (most of us are tasked to write something we have never done before), why would you if you could only use one block? It is still reasonably stable after all. If it works, it works right?

As developers, we only need to care about what needs to be delivered short term. It is never in our best interest to think about anything beyond the delivery date. This problem is even compounded by ‘software fog-of-war’ (article on this coming soon).

And because of this, estimates are worthless. A feature may just be as simple as inserting a new block but it has the potential to break the whole tower. And when it does, you have to do it again, and again and again until you succeeded in inserting that stupid block. Only to find out in the next iteration that you have to insert another block beside it and you placed the previous one diagonally (that’s also a reason why I don’t think Scrum is a good idea).

Now try telling that to the Product Manager. How are you going to explain this to them? We need to get things done but doing so breaks the whole thing. It feels like every development is defusing a bomb. Any wrong move may break the whole project. This becomes a source of perpetual anxiety for developers. We are always on the edge (perhaps that’s also due to the ungodly amounts of caffeine we consume).

Why we want to rewrite

New software is malleable. It can be molded to any form the developer desires. It can shape as fast as the thoughts of its creator. But like clay, software hardens over time. It becomes brittle. The freedom and joy that a new code provides starts to fade and slowly turns into a stressful activity. However, this is the reality of software development. We just have to live with it. Nevertheless, who told us that we can’t write new software as a hobby? I know I do and that keeps me from burning out. That’s why I keep my 99 repos around.