Staying DRY in a WET codebase

November 13, 2021

There’s an often uncomfortable tension between DRY and WET code. For all its merit, DRY can also be problematic.

But sometimes, WET is just a really, really bad idea. Usually when it means duplicating business logic. By having that logic live in two or more places, we greatly increase the chances of bugs creeping in when only one instance is updated.

Is there any way to balance these concerns?

One approach is to WET your code—that is, duplicate the business logic in two or more places—but then have an automated test ensure that the different implementations always produce the same results.

This approach is used in some fairly prominent code bases, including the Go standard library, where the cost of an additional dependency is high, but implementations must remain consistent.

Related Content

DRY can be expensive

Don't repeat yourself! Except when doing so might be harmful...

Better code review

How can we encourage less superficial code reviews?

How can I eliminate technical debt?

You can't eliminate technical debt. Nor should you want to. But where does that leaev us?