How to Avoid Structural Rot in Software

Interesting post yesterday over at DZone about why applications rot, and how to avoid it. The author, Kirk Knoernschild, argues that the best way to avoid rotting design is to reduce dependencies in the architecture. That's kind of a circular argument: what's the best way to avoid a system where a change in one place affects lots of other things? Why, reduce dependencies of course! But since dependencies are impossible to avoid completely, this "solution" is incomplete at best. What we also need is to constantly remind ourselves to leave things in better shape than we found them.

It's like fixing your house. Let's say you want to redo your bathroom, but in the process of ripping out all of the old fixtures you discover that the joists in the floor were never built right. Do you just ignore the problem and put in all the new stuff and hope for the best? Or do you suck it up and absorb the cost and time impacts of replacing the joists? Well, if you want your house to last another 30 years, you do the latter. If you don't give a shit, well then you need to get some integrity.

This isn't easy. What is easy is to get caught up in deadlines and budgets and to cut corners and make exceptions. But short term cost and time cutting will almost always lead to long term headaches. If you make a point to always leave things just a tiny bit better than you found them, you will continually improve. If you don't, then things will simply rot.

Read That Rotting Design | Javalobby.