Section 12.2. When Good Projects Go Bad

12.2. When Good Projects Go Bad

What are the signs that an environment or a whole project is in trouble? One major red flag for project rot is when the documentation, tools, or platforms are never updated. Another clue is when a product depends on old, unsupported versions of compilers and operating systems, since eventually the product will become unwanted or unusable by customers. If the documentation is never updated, it's often more confusing than not having it there at all. These changes occur over a period of years, so they are long-term indicators of trouble.

Specific signs to look for in a project are web sites full of outdated documents, and too many of the web site's pages left blank, to be filled in later, which really means never. In companies, outdated organization charts with too many unfamiliar names are a warning, as are mythical team meetings that never, ever happen.

Another clear sign of a project losing momentum is when people within the project can no longer say who owns each part of the project. As people leave and their areas are not passed on to others, those parts become stale, scary places where the rest of the group fears to make changes. Just to be safe, they will often not apply even small changes being made throughout the rest of the product to these areas. Even in projects that claim to practice "egoless programming," where any developer can make changes in any part of the code, people still know who to ask about each area.

Other obvious signs of a project in trouble are bored developers and the consequent high turnover as they leave for more interesting projects. One cause of such boredom can be lack of vision for the project, so that there are not enough new ideas to keep anyone interested. "Us and them" ways of talking about different groups in a company, or treating another group as though they are competitors, or communication failures due to personal animosity between developersthese are all signs that a project is having difficulties. Boredom and unowned code will also lead to increased numbers of broken builds and bugs that reappear after they were supposedly fixed.

On a more positive note, one sign of a project turning around is when people get around to doing things that they could have done a long time ago. Deleting old source code is a good example of this (it's still safe in the SCM repository if you need it).