As you know, the practice of refactoring is to account for software changing over time–presumably improving. Is that a myth? To some degree, I wager yes. Here’s why… and it’s not what you think.
Over the last few weeks, I’ve been involved in a fire drill to improve the reliability of enterprise messaging (via JMS) for a set of messages that transmit financial-related data within the organization I currently work. Said enterprise messaging library is approximately six years old and has had many features (as you can imagine) added to it over the years.
Upon initial inspection, it is quite clear that there is a significant amount of “Copy-n-Paste” coding involved in creating the additional features. Clue 1: Copy, paste, mutate does not constitute refactoring! Where’s the craftsmanship in that? Software quality, reliability, and readability degrades over time because software developers often just don’t give a damn. They lack pride, care, and craftsmanship. It’s as hard to find a good software person as it is to find a good doctor, mechanic, etc. Is that the company’s fault?
OK venting aside, I maintain software truly can improve over time. But as with anything (e.g. relationships, gardens, food, coffee), software requires tending. Software is never done so we need to be dilligent and deliberate with our changes. Companies need to account for total cost of ownership and allow time for refactoring to occur during the introduction of new features. Of course, that implies software developers have the inclination and skills to improve the software over time.