[nowarninglabel]

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.

[hammerdr]

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.

[tjr]

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.

[mullr]

"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..."

[hammerdr]

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.

[gruseom]

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.