That's How We've Always Done Things Around Here
Why software teams stick to old habits—and how to challenge them.
There’s an old joke I relate to a lot:
A young woman was preparing a turkey for a family dinner and, as she'd always seen, she cut off the tail before putting it in the pan.
Curious, she asked her mother,
“Why do we cut off the turkey tail before cooking it?”Her mother replied,
“That’s how my mother always did it.”So they called grandma and asked her,
“Why did you always cut off the turkey tail before cooking it?”Grandma laughed and said,
“Oh, honey—that's just because my pan was too small!”
They have been following the same ritual without knowing why.
In software engineering, we do this more often than we’d like to admit. Tech is full of turkey tails.
Turkey Tails in Software Engineering
I bet you’ve heard this before:
“I don’t know. 🤷♂️ That’s how we’ve always done things around here.”
Some teams follow tedious processes without knowing why each step exists—or whether it's still needed.
Others replicate overcomplicated architectures from past projects without adjusting for current context (e.g., two engineers now vs. 24 engineers then).
Many teams answer the same old three daily stand-up questions just because Scrum says so, even if no one’s listening.
Not convinced, yet? Here are a few more turkey tails:
Limiting the line width to 80 characters (even on 4K monitors).
Clinging to outdated team rules.
Keeping a TODO in the codebase… for 6 years.
If left unaddressed, these legacy habits will slow the team down, confuse new hires, and get in the way of better solutions.
Cutting the Tail
There are two sides to the same coin.
On one hand, we blindly adopt what we are doing without asking why or how.
When you hear“that’s how we always do things around here“, try:
Asking clarification questions,
Suggesting simpler or more current alternatives.
Testing whether the process still serves its purpose.
On the other hand, when we lead, we often focus too much on what to do, not enough on why or how.
If you’re in a decision-making role—technical or otherwise:
Make your thinking visible.
Involve the team.
Document the trade-offs.
Traditions can be helpful, but unquestioned traditions may become baggage.
—Alex
For greenfield projects you should absolutely do what is most current and makes the most sense.
But I’ve also seen the opposite mentality, which is that just because something is old means it’s bad, and the current team could do SO much better if we just rewrote it in X language (go, rust, kotlin, etc).
Such rewrites (and often smaller refactors too) fail to take into account the countless bugfixes (and untested, undocumented behaviors) that are the result of an issue discovered and fixed 5 years ago by an engineer who no longer works at the company. And the frontend depends on the old behavior so by refactoring the backend to what seems “right” you’re actually breaking things, for no real gain.
Of course old things need to be fixed because they accumulate a lot of cruft when not actively pruned and cleaned up. But when doing so, you have to exercise caution and test it well!
Great article, Alex! I love the analogy !! 👏