Don’t Repeat Yourself – DRY

posted by Matías E. Fernández on 2017-02-18

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.

Summary

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.

Challenges

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.

Unclear Responsibilities

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.

Solution

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.

Results

Clarity and Transparency

System boundaries and responsibilities are always clear and comprehensible. Efforts can be estimated more easily and estimations become more accurate.

Higher Satisfaction

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.

Higher Quality

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.

Conclusion

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.

Matías E. Fernández