Also known as
Broken windows theory
Motivation
Broken windows theory is originally a criminology theory that couples the crime rate of a neighborhood to how well maintained and orderly it is. Psychologically we are less inclined to make a mess when everything around us is pristine and orderly
The same applies to our software development. When the entire codebase is orderly, it is more likely to stay that way. When it is a mess, we easily feel like it is permitted to cut corners and deliver sloppy work.
In order to stick to our standards of quality without compromise it is therefore necessary to keep all our code clean, and leave no 'broken windows'.
Apart from the psychological benefit, this also has the technical benefit of keeping technical debt to a minimum, enabling us to keep focus on adding value, instead of cleaning up messes from the past.
Applicability
All our engineering work.
Application
In practice this means that we do not leave 'todos' undone in our code. We want the codebase to be fully in order, and use our own sense of professionalism and aesthetics to determine when something is good enough. We also implement a full test harness and take our time to do things the right way. That means that we do not skip on documentation or refactoring. There is only one way to do things, and that is with all these included.
Consequences
By keeping our technical debt low, we keep ourselves to a high technical standard and achieve maximum productivity, speed and maintainability or our software.
Samples
Everyone has worked on projects in the past where the technical standard was not uniform and corners were cut under pressure of time. Those projects typically get bogged down in a swamp of technical debt, with developers going into hacking mode. The productivity drops in only a few weeks, and only a few heroes are able to make sense out of the spaghetti that has been created. Overall we do our clients a disservice by giving in to pressure to cut corners.