What is DRY web development?
“Don’t repeat yourself” or “DRY” web development was first formally defined by Andy Hunt and Dave Thomas in their 1999 book, The Pragmatic Programmer. Today, it remains one of the few ideas that can be applied throughout all phases and levels of software development, as its core purpose is to eliminate knowledge duplication.
Wait…what’s so bad about duplicate knowledge?
It doesn’t sound so bad, really, does it? To have more than one copy of important information? We carry around copies of our birth certificates, important photographs, licenses, and other documents all the time. So, to our very human minds, it makes sense to back up information in programming in a different way to ensure that the knowledge contained within it isn’t lost.
The problem arises when we have different ways of representing the same information or duplicate representations of said knowledge. A very simple example is a database with separate birth date and age entries. Since “age” can be derived from “date of birth,” this is considered a redundant attribute (and definitely not a representation of “don’t repeat yourself!”). If someone accidentally enters incorrect information on one of those entries, it also usually means that the other is incorrect as well, and now both will have to be changed. If those changes are not properly made, then there is a contradictory representation of the same knowledge, which can wreak havoc on your database and the sites, tools, or apps that rely on it as well as erode trust in your product.
Philosophically DRY
This happens in other ways, in other professions, and on a philosophical level, too. For instance, if you have to explain a concept or variable multiple times when teaching or handing off a project to a coworker or client, then it probably means that you’re not touching on the best variable or concept to represent the knowledge that needs to be shared.
A high-stakes example of a time when someone should limit duplicate information is during handoff between healthcare workers in an emergency. Historically, it’s one of the most dangerous times of a patient’s course due to lengthy duration, interruptions, repetition, and other forms of unclear communication.
One of the most widely used tools in patient handoffs, the SBAR tool (and all of its derivatives), was adapted from the military for use across healthcare specialties to streamline handoffs. SBAR stands for “situation, background, assessment, recommendation,” which are the four most essential pieces of information for a healthcare professional to take over the patient’s care safely.
SBAR works because it simplifies the vital information necessary to assume care and allows providers to share a mental model of what handoff ought to look like. By identifying the most correct and simplest variables, clinicians don’t repeat themselves, saving critical minutes in life-threatening situations.
How do we stay DRY in development and life?
Now, web development does not always carry the gravitas of life and death like healthcare work, but there are certainly plenty of times when a great deal of workplace headache and confusion can be eliminated by thinking about its purpose - the exchange of information - in the simplest, most straightforward terms.
In a vacuum, you’d want a database, backend, frontend, and documentation library that has no knowledge duplication anywhere, but that’s not always possible or practical. The good news is that DRY web development is not a hard and fast rule or a programming language; it’s simply a principle used to guide the exchange of knowledge. So developers or project managers can pick and choose how they implement this principle, and that implementation is likely to vary depending on the use case. Here are three things developers and project managers can do to adhere to the principle of DRY web development:
Abstractions
Abstraction is one way to apply the principle of “do not repeat yourself” to logic. For example, we often use abstractions when designing classes into which we sort data points: when more than one class shares a common governing logic, we can abstract that logic into a superclass. That superclass’s logic is then inherited by each resulting class.
Abstraction is an essential aspect of standard object-oriented programming (OOP), as its practice encourages the production of readable and reusable code that’s easy to maintain. In fact, by definition, OOP keeps only the essentials and removes all unnecessary information about said objects. And if that’s not representative of DRY web development, then what is?
Normalization
Normalization is another way to apply the DRY principle to logic. Well, almost even before you start applying logic, you can normalize to determine the most efficient labels or buckets for the most basic pieces of data. An integral part of Edgar F. Codd’s 1970 relational database model, normalization is a set of procedures that seek to eliminate non-atomic values and resultant redundant data. This process prevents data manipulation anomalies and loss of data integrity, creating a single, reliable source of truth for your database. Incidentally, it also makes your data more flexible and scalable—a win/win for sure.
One drawback of normalization is that it can become easy to over-engineer if you normalize too granularly, which can also slow down data retrieval and impact performance. That’s where smart data strategy comes into play: Strategic data planning can help determine what variables, and to what degree, to normalize that makes the most sense over time.
Automation
Automation is a way we can apply DRY web development ideals to processes. Not only does automation allow us to deliver products more quickly and efficiently to clients, but it also reduces repetitive tasks like regression testing, some types of code review, and continuous delivery.
A word of caution with automation is that team members should still communicate with one another to limit repeating completed work and allow the mutual exchange of information. In other words, just because a task is automated does not mean that it doesn’t need to be validated by a human and acknowledged between team members. Remember: human validation is not considered “repeating yourself” in the context of automation.
Limits of the DRY approach
In general, DRY web development yields simpler, cleaner-looking code that can be handled more easily by more people, but that’s not always the best thing to end up with. Some might argue that it’s too blunt of a tool and that duplication is better than being entirely wrong, especially in the cases of unit testing and premature abstraction.
Especially when inheriting someone else’s project from the past, it can be easy to rush in and try to “simplify the code” by creating a clever abstraction, but why try to solve a problem that doesn’t yet exist? Sometimes, it’s better just to duplicate, use it in production, and only revisit when an actual problem arises. You don’t have to create a contingency for every single possible way someone can break your code. In other words, if it ain’t broke, don’t fix it.
For a non-programming example, we can go back to our healthcare team. In intensive care units (ICUs), many of which now handle patients on the edge of life and death for several days or weeks, care teams often find SBAR to be insufficient to provide the high level of assumed care in these environments. These teams have instead evolved the mnemonic to include a full system report, including devices, lines, medications, plan of care, and more.
From a data perspective, one could argue that if a patient is on a very specific medication with a very specific indication profile, it can be deduced that they must have the corresponding very specific diagnosis. And from the outside, from a purely data-centric perspective, that is most definitely knowledge duplication. But in the practical application of clinicians performing bedside reports, this knowledge redundancy literally saves lives.
In short, while it’s satisfying and often useful, the DRY principle isn’t always the best approach to programming or life. So what do we take away from this? Build something that works, is easy to decipher, and is easy to change or even delete. And don’t be offended when some newbie inevitably deletes your code: Remember—even if you manage to use the right abstraction from the very beginning, a new language, paradigm, framework, or platform will eventually come along and render that work an absolute dinosaur before you know it. :)
Think we know what we’re talking about? Want to work with us?
We love helping our clients solve problems, both with and without technology. From brochure WordPress websites to full product suites and everything in between, from start to finish, we design and develop with practicality, flexibility, and personality. Is it always DRY? Nope. But we do our best to keep our work easy to use and change over time, with our clients’ goals always at the forefront.
