Is Your Software Rotting?
pragprog.com
pragprog.com
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.
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.
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.
@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..."
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.