Why Bad Code Thrives: Lessons from the Trenches

Xiao Wang just joined a company that’s been around for a while, so even the "shit mountains" are fermented and smell strong.

Like many unlucky programmers, he ends up fixing these "shit mountains" and adding more bricks, often cursing the system designers as garbage.

Sometimes the original designers have already left, or they are the direct supervisors. A seasoned mentor may regretfully admit that the system is riddled with flaws and wish it had been designed correctly from the start.

Everyone regrets bad code at some point, just as investors regret losing money on stocks.

People often judge code only after it runs; "it works" becomes the only metric. Poor code reaches production because of missing steps in the development pipeline.

Rushed Schedules

Countless managers try to quantify developers’ work with KPI and OKR tools. While useful at times, measuring work solely by deadlines leads to massive technical debt.

Under deadline pressure, few consider requirement reasonableness or future extensibility. Bad code is pushed online without review, refactoring, or adequate testing, often compromising fundamentally flawed designs.

Most short‑lived code causes little trouble, but long‑lived projects with endless patches eventually collapse, like building a skyscraper on an unstable foundation.

Hand‑On Projects

Some departments deliberately assign critical modules to newcomers to train them.

Lacking experience, newcomers produce designs with many defects, yet their time cost is comparable to veterans. These “practice” projects can unintentionally become massive systems, magnifying their flaws.

Newcomers tend to use flashy new techniques, while veterans stick to simple, proven tools, reflecting a mix of practical learning and vanity.

Such trendy code often introduces numerous conventions that clash with existing project standards, leading to inconsistent styles, debugging difficulties, and poor extensibility.

Self‑Made Solutions

Many programmers are overconfident about their English and coding skills, writing flamboyant, self‑invented code.

They ignore community conventions, naming APIs arbitrarily—e.g., calling "/health" as "/server_status" or inventing error codes like "success_200" and "fail_500"—which later newcomers reluctantly inherit.

These ad‑hoc conventions accumulate over time, becoming opaque and hard to understand.

If you encounter such terrible code, don’t rush to rewrite it; follow its existing (though flawed) logic, as it may be more stable than a hastily crafted fix.

Copycats

In many companies, products and code feel eerily familiar because they are copied.

Under budget and design constraints, bosses order teams to replicate existing solutions down to the smallest button.

Copying yields shallow thinking and inferior detail compared to original designs, and the source itself may change, leaving the copy outdated.

What to Do?

Regret is better than never regretting; it shows awareness of the right approach, even if circumstances forced poor outcomes.

Those who have regretted can reflect on project timelines and staffing, whereas the unrepentant may be stubborn or truly convinced they are correct, which is tragic.

If you must maintain these "shit mountains," do what you can without over‑engineering or reckless changes, unless your team is given genuine time and resources to clean them up properly.