Duplication isn’t evil, it’s a balance.


Exasperated Business Person: “Shouldn’t that be easy? I’m asking for a single change.”

Exasperated Engineer: “Right, yeah. It’s hard to explain but the Sorting framework is a really hairy layer, and then I have to remember to make changes in module A and B, and they’re really fragile…”


Duplication is what drives these conversations. Having to make a change in many different places is difficult. It’s hard to think about, hard to remember all the details. There’s a lot of risk. It gums up your works, man!

On some scale, duplication is good. It makes the ecosystem diverse. It’s a very good thing that there’s tools, frameworks, and languages to choose from. I’ll make the case that local codebases aren’t an exception.

One True Way

I’ve seen codebases that insisted on One True ways. As soon as a concept or tool was chosen, it was crystalized as The Right One- to be used forever and always.

The upside is familiarity, any developer can sit down and already know how to interact with the system. The downside, was it has to make the system simpler. We couldn’t try different ways. We couldn’t even test if we needed that tool. The trade-off was Ease for Simplicity. The Hickey’s epic Simple Made Easy talk explains why that’s a poor trade-off.

I tend to favor multiple approaches. Sometimes when I don’t know the way forward, I’ll try out a few different approaches. I’ll reserve some hours at the end, to re-evaluate the solutions. Maybe I need to combine them to one. Maybe I don’t- sometimes making a few approaches can stop Premature Abstraction. I might be feeling uncertainty about solution because I’m sensing but not realizing that there are differing requirements. That one solution won’t work.

The time it takes for a developer to familiarize themselves with a new tool is a good price to pay for the ability to keep systems simple and agile.