As I'm sure you are aware, all-too-often that is not the case. Too often, time is constrained, resources are low, talent is scarce, requirements are flawed, or budgets are tight. Whatever the reasons, most projects eventually become rancid and require either a major re-design or a total rewrite. No one wants to face it, but the truth is, some hopeless projects are even rancid right out of their packaging.
What do I mean by rancid? I mean code that's a waste of time--literally. I mean code that's costing you more time to fix, patch, and improve than if you were to just rewrite it from scratch. But how do you know? How can you, as a manager, determine that a project really is a hopeless cause? You certainly don't want to jump right in at the slightest hint of decay, and start redesigning perfectly salvageable projects. But if a project really is rancid, the longer you delay, the more damage you will cause. Not only will you waste valuable time, but you may also squander precious credibility with your clients as they ask for fixes and all you can offer them is failure after failure. So, again I ask, how do you recognize truly rancid software? What does rancid software smell like? Here are some common rancid odors to look out for:
All software has bugs; that should come as no surprise. Even good software can have some really difficult to solve bugs. Hard-to-fix bugs, alone, aren't a sign of rancid code. However, when there is a never-ending flow of bugs, that is a classic sign of rancid software. The bugs may not always be critical in nature, or even overly difficult to fix, but every time they are fixed, a new set of seemingly unrelated bugs always crops up. It's like playing the old arcade game of whack-a-mole. You smack one bug down and another pops up. When you see this pattern continuing for an unusually long period of time, know that it is the stench of rancid software.
Even well-designed software may have an occasional critical bug, but it won't have lots of bugs in its core functionality. Bugs should typically be found in fringe features, unusual circumstances, and unexpected use cases. When an application continually has bugs in its core functionality, that's not normal--that's rancid.
If there is a game-changing enhancement that needs to be added to a product, you should expect it to take some time to complete, but if predictable enhancements which are seemingly simple in nature are a major undertaking, the product clearly wasn't designed well up-front. Typically, enchantments to rancid software become increasingly difficult over time.
When you encounter a particularly difficult problem in an existing application, it's only natural to call on the expertise of its lead-developer. The one who designed, wrote, or "owns" it is typically the best equipped to solve the problem. Or, at least, that's how it should be. When the lead-developer is just as ineffective, or even worse--less effective, than other developers, that's a strong sign of hopelessly rotten code.
Some people claim to have seen Bigfoot in the wild, but sightings are rare, descriptions are confused, evidence is sketchy, and no specimens have ever been observed in captivity. Bugfeet are the same way. Bugfeet are bugs that are randomly encountered and cannot be reproduced. As with the other rank odors, one or two of these in the life of a product is not necessarily an indication of rancidity, but a pattern of frequent Bugfoot sightings definitely doesn't smell right.