Why “Best Practices” Can Be a Double‑Edged Sword in Software Development

“Describe a thing: only one noun defines its concept, only one verb reveals its behavior, only one adjective shows its trait. The task is to find that noun, that verb, that adjective….” – Gustave Flaubert

I want to tell a story.

Long ago, two senior engineers discussed their proudest projects. One described a massive bridge built after years of geological study, material selection, design, and construction, complete with rail, bike lane, and toll booths.

The other recalled a humble rope bridge that started as a simple rope across a valley, evolved into a market town, and eventually became a steel suspension bridge, while the first engineer’s grand bridge was later dismantled because it was built in the wrong place.

This tale, originally from the ZeroMQ guide, leads to a discussion of the concept of “Best Practice.” Wikipedia defines it as a method accepted as superior because it yields better results or becomes a standard.

Best practices originated in management theory and spread to IT, essentially meaning “the correct way to do things.” While noble, they can become a burden.

First, obsession with best practices can create mental baggage, preventing focus on the actual problem. Engineers may chase the perfect technique, over‑engineer, and delay delivery.

Second, it can misdirect priorities, emphasizing standardization over user experience or real needs. The story illustrates this: the textbook bridge met standards but failed users, whereas the improvised rope bridge solved the core need.

Examples follow: Plan‑9 OS attempted to perfect the “everything is a file” Unix philosophy but never solved real problems; PHP powered Facebook’s early success despite criticism, later replaced by Hack when needed; HTML and JavaScript, foundational web technologies, are far from perfect yet power the modern web.

The author shares personal anecdotes—forcing Git on a team that only knew SVN, and a colleague’s unrealistic 12‑month mobile game timeline—showing how rigid adherence to “best” tools can backfire.

Ultimately, best practices are a mindset, not a universal rule. Timing matters: applying a practice at the wrong moment can be detrimental.

In conclusion, the author suggests that the “best” language or editor is less important than pragmatic, context‑aware decisions, humorously ending with “the best practice for choosing a language or editor is violence.”