DevOps and the DRY Principle

Formatting code correctly and adhering to best practices is crucial if you are developing software as part of a team. So, a good software developer needs to be mindful of the many and various conventions, both formal and informal, which exist for writing code. When everyone is using the same formatting and the same protocols, it ensures that code written by one developer can be read and understood by another—quickly! And this is the key.

As part of any DevOps strategy, developers should look to formulate a best-practices policy for all their employees to follow internally. This set of best practices will ensure that everyone on your team is on the same page and working to the same standard. One of the key principles that any DevOps strategy should embrace is that of DRY coding. While it may sound like a tasty cocktail, DevOps and DRY (Don’t Repeat Yourself) embrace the ideals that you should only write quality code once, the first time.

DRY or WET?

The opposite of DRY is WET (Write Everything Twice). WET code is code which repeats itself often or refers to how developers spend too much time reworking unclean code. This is something that you should be looking to avoid. Duplicated code is typically a sign of code stink and also often redundant. There are often far more elegant ways of reusing code blocks. Adhering to the DRY coding principle means that your code will contain as few repetitions as possible.

There is, of course, a purpose to DRY coding. Not only does it make code more efficient and readable, but it also encourages coders to observe other best practice conventions. For example, DRY motivates us to create reusable functions or subroutines which can be called upon later. The practice also incites developers to look for more elegant solutions to any problems they encounter.

At this point, many readers may stop reading and be saying to themselves, “But I need to innovate and iterate quickly.” They’ll perhaps also follow that with, “These so-called ‘best practices’ will only slow me down.” And I agree, the first steps are always the slowest for the initial creation of any resources. But any developer that has actually put this practice to the test will contest that the effort quickly yields results.

Below are some of the key advantages of sticking out with the initially slow process of adopting the DRY principle.

Quality and Integrity

The key benefit of DRY is the improvements to code integrity and quality that it offers. When you encounter a bug in your code that needs addressing, it can be hard to pin down at the best of times. If you have lines of code regularly repeating, identifying the instance where there is an issue is much more difficult. In such a scenario, you will also have to go through all your duplicate code and ensure that you apply any tweaks and fixes to all instances where that code is used. These fixes are no less true for Infrastructure as Code as they are for normal software code too.

In contrast, when you are instead calling the appropriate function each time, you only need to make adjustments to that one. Whenever the function is then called, it will itself execute correctly. The improvements in efficiency that are achievable with DRY coding can make a considerable difference to your overall development time.

Legibility

This is connected to the integrity of the code. Code that is easier to read will be easier to comb through for bugs. But legibility is useful for more than just allowing coders to read code more easily. Having a repository of highly readable and highly organized code makes for an excellent training tool. When you are demonstrating to new team members how you want them to approach their formatting, and which best practices to observe, you can show them these examples.

Recycling

Adhering to the DRY principle encourages coders to look to formulate reusable functions and subroutines as much as possible. One of the benefits of this approach is that you often end up with lots more recyclable code. Your team will often find themselves developing functions for one project that have some exciting potential uses in a different project. You won’t just increase the efficiency of your development of the application in question, you could potentially speed up the development of a number of other projects as well.

Expense

As a general rule, the more code you have, the more expensive a piece of software will be to maintain. More code means it takes longer to identify and fix bugs. In software development, technical debt refers to the recurring costs of additional maintenance work that inefficient coding requires. More code means that tech support staff have much more to review and monitor. And, most importantly, more code means more opportunities for bugs and other errors. By reducing the amount of code that is used in each project, you are also reducing the long-term expense of that project.

DRY Observations

While the DRY method offers numerous benefits, it is important not to become overzealous in your implementation of it. If you aren’t careful, this otherwise useful technique can ultimately end up working against you. Adhere to the following addendums about DRY code:

• Not all code needs to merging: While it is a good idea to work with reusable functions and subroutines where possible, it is also important to recognize situations where this isn’t appropriate. There are times where two pieces of code can appear to be almost identical, with just one subtle change between them. In some cases, these functions can be merged into a single function which can use either arguments or logical statements to perform both roles. However, in some cases, completely different functions are required, and the code should not be merged.
• It can become too DRY: If you go overboard with the DRY approach, code can go from becoming more legible to becoming completely unreadable again. If you have a piece of code which is only called or used once throughout your software, there is no need to package it as a function. It will be confusing for any other developer who looks over the code to see a function defined and then only called once. This goes against common practice, and therefore works against any readability you were trying to gain. You aren’t avoiding duplication here, in fact, you are adding to the amount of redundant code.
• DRY beyond code: It isn’t just your code that can benefit from the DRY approach. You can also apply DRY to testing and documenting your code, as well as database design. (For more on database design best practices, read our blog post here.) Once you start to use DRY, look for opportunities to expand it into other areas of your business. You might be surprised by just how much of a difference it can make to all aspects of your business.

The DRY principle can be a game changer for developers who are in search of a way to improve their efficiency—as per the DevOps methodology. It won’t just make each individual project much easier to maintain and work with in the future; it will also encourage your coders to observe other DevOps best practices.