Component-Naming Rigor (CNR)

Whenever software engineers are asked to list the most difficult aspects of their jobs, the problem of coming up with good names for their components is always somewhere near the top of the list. Naming components is difficult for the same reasons that naming products is difficult. When you try to find a good name for a product, it can be a significant struggle to find one that is unique within the industry, memorable to the consumers, and yet still meaningful to everyone. Software engineers face the same predicament when naming their software components, but they go through it multiple times a week rather than just once a year. When they create a new class, type, data-structure, or module, they need to give it a name that is unique, memorable, and meaningful. If they fail to do so, they will not only confuse other developers, but they will even confuse themselves.

Rancid-Code Smell

Software, like food, can become rancid. Over the course of time, as new-features are added, adaptations to new technologies are made, and bugs are fixed, all software will begin to show its age. If software is designed well up-front, it will keep for a long time. Even the best designed code requires a fair amount of refactoring, of course, to keep it fresh, but, when it is maintained properly, well-designed code can keep for decades.

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: