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.