This is the third instalment in a series of articles about six core principles that my team, a software development team, and I compiled in order to develop a framework for decision making. The reason for building the framework was to build a common understanding of how we want to work. Writing it down allowed us to easily transfer that knowledge to new colleagues and to spread the word.
In this article we will have a look at a principle called DRY – don’t repeat yourself.
DRY is a principle aimed at avoiding duplication, or at least reducing redundancy:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
– The Pragmatic Programmer by Andrew Hunt and David Thomas
Duplication – specifically in regards to code, e.g. scrips, apps, etc. – required increased effort for maintenance and refactoring. Thus all knowledge and all ressources should have one authoritative representation in the system, e.g the app or the SOA infrastructure. Besides code this applies also to documentation and architecture.
Complex and Expensive Maintenance
Having redundant code, or documentation, requires that changes be manually applied at multiple places. This requires extra effort is error prone.
If one and the same problem is solved in different places, and probably in different ways, through code duplication and slight modification, then it becomes unclear which instance of the code is the culprit in the case of errors. It makes debugging hard and tedious.
Difficult Quality Assurance
Patching errors in duplicated code requires all affected parts of the system to be tested individually.
Dissatisfaction and Frustration
Making changes to a system suffering from code duplication makes it almost impossible to estimate effort and cost of the change. Oftentimes several parts of the code have to be fixed, turning supposedly easy fixes into complex endeavours. This causes frustration and dampens motivation.
The following solutions have been summarised in an article titled Curly’s Law: Do One Thing by Jeff Attwod.
Once and Only Once – OAOO
Each and every behaviour should be implemented once and once only. This is one of the most important goals during refactoring. It is a design goal to eliminate duplication. This can be achieved by encapsulating behaviour in a reusable class, module or library. See also Once And Only Once on the Wiki Wiki Web.
Single Responsibility Principle
Clear system boundaries provide clarity in regards to responsibility. It is a design goal that a (software) component has a single responsibility. See also the Single responsibility principle on Wikipedia.
Clarity and Transparency
System boundaries and responsibilities are always clear and comprehensible. Efforts can be estimated more easily and estimations become more accurate.
The software development process becomes more agile, encapsulation enables reusability. Changes can be done faster and with less risk, this improves motivation and satisfaction of team members.
Reused parts are more broadly tested in the field. All systems reusing the shared parts benefit from improvements while, due to encapsulation, the parts can be tested more easily.
Applying the DRY principle substantially lowers the effort for maintenance and development of software systems, thus increasing agility and resulting in a more productive and motivated working environment.
- Don’t repeat yourself on Wikipedia
- Dont Repeat Yourself on Wiki Wiki Web
- Don’t Repeat Yourself on 97 Things Every Programmer Should Know by O’Reilly
From Dev-Team with ❤