Practice 1. No "Broken Windows"
This practice could also be thought of as "no hacks or ugly workarounds." It is possible to think of many metaphors for this practice. The authors of The Pragmatic Programmer [Hunt and Thomas 2000] use the metaphor of a house for software development, where once a house has a broken window, the occupants of the house will tend to be careless and more prone to leaving broken windows themselves. Another metaphor for this practice is counter space in your kitchen: All it takes is for someone to leave an unopened letter on a section of your counter, and before you know it, there will be more there. Software has all the same properties as a house or kitchen countertop: It's exceedingly easy to make changes in a sloppy, haphazard way. Once one sloppy change has been made, others will follow; this is unfortunately human nature. Therefore, never start the decay, and if you find some bad code, clean it up immediately. If the programmer who left the mess behind is still working on the code, make sure he or she knows about the cleanups you have made and why you made them; peer pressure to write good code is a good thing.
In software, once decay has started, the decay will continue and get worse over time. It is really hard to care about leaving the code in a good state when there are obvious signs of neglect. This is unfortunately human nature, and the best way to combat human nature is to always leave the code in a better state than when you started. Don't leave a mess behind for someone else to clean up! Ugly workarounds cause problems and are a symptom that the product is most likely not in a working state.