Broken Window Theory
The broken window theory is a criminological theory that states that visible signs of crime, anti-social behavior, and civil disorder create an urban environment that encourages further crime and disorder, including serious crimes. The theory suggests that policing methods that target minor crimes such as vandalism, public drinking, and fare evasion help to create an atmosphere of order and lawfulness, thereby preventing more serious crimes.
The "Broken Window Theory" has inspired police departments in New York and others major cities to crack down on the small stuff in order to keep out the big stuff. It Work: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.
What these means in reality?
Several cracks on the car left unrepaired for any substantial length of time, make sense that nobody doesn't care for the car. So few more cracks appear on the car and after that serious structural damage begins. In a short period of time, the car becomes damaged beyond the owner's desire to fix it, and the sense of replacement becomes reality.
Continuously fixing the cracks one by one is cheap, but buying a new car is very expensive. The same is happening for the software.
What these means in the software?
I think that you realised :)
Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.
You may thing that no one has the time to go around cleaning up all the broken glass of a project. If you continue to think like that, then you'd be better plan on getting, a dumpster, or moving to another neighborhood. Don't let entropy win.
From where to start?
That is most probably depends on the project but I can give you one tip.
Write Tests
Getting good developers to write tests early and often needs to be part of the development process to keep down bad grades, and believe it or not, speed up development. "Tests are great, "but we don't have time to write them," is a MYTH.
Writing tests almost always has a positive impact on a project's development time when done right. Yes, tests do involve code that takes time to type out. But that time is returned in a couple of different ways.
If a window breaks in a house that is being lived in, someone fixes it. In an abandoned building, no one knows that it's broken. Things deteriorate over time in an abandoned building. Replacing a window is easy, but remodeling an abandoned building is a lot of work. Buy running tests often, it is part of the build process, you're living in the building of your applications test.
Counting tests, or looking for 100% code coverage, encourages writing bad tests and wasting time. What you measure is what you get if success is ten tests per feature. Some features will have time wasted on testing. Some will not be tested enough. 100% code coverage with tests is probably a waste of time, unless you're writing code for a space shuttle.
I hope that you will find useful things on this article.
Toni