When Is Rewriting Code Worth It? Lessons on Cost, Risk, and Value

From a company perspective, if a system is already released to customers, rewriting it is not advisable.

From an individual perspective, one may rewrite privately to improve skills, but should not attempt to replace the live version.

Newcomers often see only superficial issues like messy code, overlooking the many problems already solved by the system.

Even experienced developers may fail at rewrites because memory of past decisions fades, leading to suboptimal solutions.

Key argument: It's harder to read code than to write it.

Writing code is easy, reading code is hard.

Main points:

Even if rewritten code matches all functionality and performance, the product gains only marginal competitive advantage; code clarity mainly reduces long‑term maintenance cost.

Rewrites consume extra time and money; unexpected issues (budget cuts, staff turnover, unmet performance) can make the effort disastrous, sometimes resulting in a product that fails or is inferior.

Good architecture design early can lower hidden maintenance costs, but after a project is live, rewriting usually offers at best marginal benefits while risking failure.

If a project is so outdated that new features cannot be added, creating a new project and rewriting there is the sensible choice.

Ultimately, recognizing problems as opportunities and aligning code decisions with business goals determines success.

Source: Zhihu discussion (http://www.zhihu.com/question/29941041)