The Wisdom of the Lead - a Gemini story
When I first started as a developer, I was absolutely convinced that the most efficient way to build software was to follow the DRY principle (\text{Don't Repeat Yourself}) to the letter. This conviction quickly clashed with reality on my very first major project. We were tasked with launching a new "Gift Card" program. The requirements came down from the business and explicitly stated that the new cards would function "exactly like the existing Gift Certificates," which were a legacy product. I saw a huge opportunity for efficiency. "If they work exactly the same," I argued to my Lead—a guy who'd been with the company for decades—"we shouldn't write new code. We should just reuse the battle-tested Gift Certificate code and save six weeks of work." My Lead, a man of few words, just leaned back and gave me a look that said, "Oh, you sweet summer child." All he said was, "Just write the new code. And watch." I was frustrated. I thought I was being forced to create technical debt through duplication. But I did as I was told. Over the next six months, I watched him be proved absolutely, spectacularly right. The requirement didn't change with a bang; it changed with a thousand quiet, frustrating whispers. First, the cards needed a different funding ledger, then a new issuance workflow for physical stores, and finally, Legal got involved, demanding completely separate audit trails for liability. The new "Gift Card" eventually became an entirely different product with its own architecture, databases, and processes. My initial idea to reuse the old code would have caused us to tear apart and rewrite a stable legacy system, introducing bugs and months of delays. The Lead knew that when a new, high-profile product is launched, the initial requirements are never the final ones. He wasn't optimizing for the requirements on paper; he was optimizing for the inevitable political and legal complexity that would emerge. His one line—"Just write the new code. And watch."—was the most profound lesson on architectural foresight I've ever received. I stopped seeing code reuse as an absolute good and started seeing it as a choice that must account for human nature and business evolution.
Context:
Sometimes "the business" quite literally doesn't know what it is talking about.
For example, one time we got a requirement for gift cards which we were reassured in writing will work exactly like an existing product -- gift certificates. I argued if it works exactly the same, we shouldn't write new code for it, they it should just use gift certificates code. Lead said just wait and watch. Of course, over the course of the next six months, the whole requirement changed little by little at first until they were completely different. The key was these two had completely different workflows, who issues them, where the funds live, I don't even remember any details but I am sure legal was involved at some point.