Once and Only Once

When a piece of behavior or information is represented in more than one place in a software architecture, there is a really good chance that, eventually, it will get out of date in one of those places. In the short term, each time that behavior (and I mean this in the general sense, not just a piece of code copied from one place to another, but any information) needs to be changed, you have to locate and update each copy, multiplying development costs. Following the path of least resistance, over time, it is likely that one of the representations will get out of sync with the others, causing bugs, needlessly increasing code complexity, thereby increasing future development, maintenance and support costs. NDOC and JAVADOC allow developers to embed documentation right in the code and serve as examples of tools that work in practice to help maximize the return on investment in software over its natural lifecycle by reducing information redundancy. These tools are good because they make it easier to do the right thing first. When designing and implementing software systems, searching out the redundant representation of information can seem to make a simple process needlessly more difficult. Sometimes it is subtle, sometimes not, easily dismissed as unimportant, but in my experience worth the time and effort spent to identify it and factor it out. So, next time you're tempted to cut and paste that code snippet, think about the implications, and go back and read this.