Is Your Software Rotting?
pragprog.comAs I see it, software rots because though maintenance is a permanent and recurrent cost, the ultimate cost for it (codebase abandonment) lies in the distant future.
By the time it is needed to flush the big ball of mud down the toilet, the people responsible would have probably gone on to better things. Or to another big ball of mud project in another company.
I guess it is a case of misaligned incentives.
Personal experience:
In one of my previous positions, as the most senior engineer on board, I was asked to survey our system to determine whether it was suitable to be the basis of yet another deliverable project.
I spent a month doing this, wading through the big ball of mud which came into existence over the course of five years and delivering three projects (barely) using this codebase.
My assessment was pretty honest and I asked for time to attempt paying down this technical debt to a reasonable level before we go on ahead to use the code base on another project.
Management, at the end, did not authorize the "debt-repayment exercise". Perhaps I should have pushed harder but I was told it was "above my pay grade". At the end, they began insinuating that I was responsible for it all. Simply amazing.
Soon, I bid them adios. As I understand it, the code base has been discarded in favour of complete redevelopment. Which will take another two to three years.
One corollary to this, working off the same metaphor, should be that sometimes it's easier to just come in a redevelop the neighborhood than to try to fix its problems. This is my plan for a piece of software where making small fixes in it, only leads to exposing other more dire and deep-seated issues.
I would argue that developers will tend to have a "this is too much Bad, lets rewrite it" perspective.
It is good to temper our desire to write it our way with the realization that software that is hairy is often because of hairy business requirements. A steady application of clean code boyscouting is really the only solution to a large system with unknown but inevitably complex business rules.
Edit: But, sometimes, it is better to rewrite it. Usually this is by rewriting subcomponents or "rewriting" software by create a new stack for a new feature that'll phase out old software.
As a freshman studying calculus and physics, it's tempting to think that the world is a stunningly mathematically beautiful place: motion and speed and acceleration described so elegantly by functions and derivatives! But in the real world, things aren't quite so pure. We don't really have frictionless surfaces or massless objects. We have to complicate those beautiful functions. The beauty is still there, but it's not as obvious.
I think likewise, we can take a big-picture look at a software project, and in our minds we see the unadulterated beautiful design. We see the elegant solution to the problem. But when we actually go to code it, try as we might, we can't stay entirely elegant. There are edge cases that the elegance doesn't handle. There are obstacles that we didn't account for, and now must work around. There are requirements changes that come mid-stream and we don't have time to start over. There are deficiencies in our own understanding of our languages and libraries and compilers, and we don't do everything in the most optimal way.
The result has a well-designed interior, but just like real-world physics, there's a bunch of other stuff bolted on. And when an outsider looks at the code, it's hard to see the beautiful inner design amidst all of hacks.
"Code boyscouting" is an excellent way to put it.
@yzhengyu's experience is representative of my own, though without the same degree of politics. Even in conversations with those who should know better, it's nearly impossible to put technical debt payback ahead of new business requirements. Attempts to quantify it (additional time to deliver = lost opportunity = money) are fuzzy at best.
I really think the only practical way to combat code rot is at the leaf nodes, without telling anybody. Perhaps we ought to have a secret oath that all developers take. "On my honor, I will do my best, to do my duty to Knuth and my Profession and to obey Postel's Law..."
We can all certainly try :) And, fighting in the trenches every day (taking some time to do some refactoring instead of calling a feature done) is a great place to start.
However, the code rot really needs to be understood by the upper management of IT. Having a solid grasp of technical debt, how much it hurts, how much debt you can take on and how long it takes to pay that down is the responsibility of any manager of IT departments. If management doesn't understand this, they are setting the products up to fail every 3-5 years no matter how hard the developers work at the leaf nodes.
I recall reading (probably in Steve McConnell) empirical evidence that most bugs come from a small number of modules and that it's typically better to rewrite such a module than try to fix it.
I can't think of a project that I've worked on which hasn't suffered from companies not understanding that you cannot build without a structural plan of some kind, and that the person charged with making that plan needs to know what they're talking about. Far too often ambition outweighs actual detailed knowledge of the subject. Whilst I accept that not every technician is cut out - or wants to accept the responsibility - there are those who take their work seriously enough to know the difference it can make. Of course I blow my own trumpet in this respect, but it's surprising how often the pay grade above choses to go against all advice and evidence, and then comes back three months later and asks for a work around to fix the mess they got themselves into. In a week, just to save their scawny ass.
As soon as it's in use, it starts to rot. This is the hardest challenge in writing software.