Constantly growing technical debt in the name of business needs. This results in a code base that makes it more expensive to respond to changes over time. More and more programmers are hired to keep control of the evolving code base. This leads to Defect-Driven Development, where developers keep introducing more defects while trying to fix them. The code is constantly monitored and hacked while trying to converge to it's original intention.
Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report: Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
"Code duplication harms the uniqueness of entities within a system. For example, a class that offers a certain functionality should be solely responsible for that functionality. If duplication appears, it becomes much harder to locate errors because the assumption “only class X implements this, therefore the error can be found there” does not hold anymore. Thus, the presence of code duplication has (at least) a double negative impact on the quality of a system: (1) the bloating of the system and (2) the co-evolution of clones (the clones do not all evolve the same way) which also implies the cloning of errors."
Michele Lanza, Radu Marinescu, Stéphane Ducasse - Object-oriented metrics in practice.
The dead code metrics measure the amount of dead or inoperative code in the source. Dead code means unnecessary, inoperative code that can be removed. Being dead means that the element is not used and you can remove it without affecting the functionality of the program.
An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.
Code-coverage has the only trend where the higher is better.
Although 100% code coverage may appear like a best possible effort, even 100% code coverage is estimated to only expose about half the faults in a system. Low code coverage indicates inadequate testing, but high code coverage guarantees nothing.
When you focus more and more on making the coverage numbers better, your motivation shifts away from finding bugs.
Constant low (~0)
Modification of the code is expensive, time-consuming and error-prone.
Code complexity can be defined as a metric which is directly proportional to the amount of effort required to understand the code and modify it correctly. Code complexity metrics are directly related to the maintainability and testability of the code. The more complex a code is, the less maintainable and testable it is. If the code is object oriented, the complexity metrics also have a direct bearing on the extensibility and modularity of the code.
"Modularity is a general systems concept, typically defined as a continuum describing the degree to which a system’s components may be separated and recombined. It refers to both the tightness of coupling between components, and the degree to which the “rules” of the system architecture enable (or prohibit) the mixing and matching of components." Wikipedia
One unrepaired window is a signal that no one cares, so breaking more windows costs nothing. . . .
If disorder goes unchecked, a vicious cycle begins. First, it kindles a fear of crime among residents, who respond by staying behind locked doors. Their involvement in the neighborhood declines…they cease to exercise social regulation over little things like litter on the street, loitering strangers, or truant schoolchildren. When law-abiding eyes stop watching the streets, the social order breaks down and criminals move in.
Understanding that such a vicious cycle exists is important in creating a higher level of discipline and ownership in your current projects. Teams who are not vigilant about immediately fixing broken unit tests or builds, are in a sense, creating a downward spiral within the project. Team members who witness a single blatant act of project vandalism will undoubtedly give into the lazy human nature and retaliate with the common quote, “Well if he isn’t going to do that, than neither am I…”. The spiral begins…