Should You Rewrite Legacy Code in C#? A Deeper Look at Derek Comartin's Take

The “Never Rewrite Code” Principle

Derek opens by acknowledging the long-standing advice often given in software development: Never rewrite code from scratch. This sentiment stems from a famous blog post by Joel Spolsky titled “Things You Should Never Do”, which strongly warns against rewriting legacy systems.

At 0:32, Derek points out the most critical idea from Spolsky’s piece:

“They made the single worst strategic mistake any software company can make: They decided to rewrite the code from scratch.”

Derek explains that the main takeaway is this: when starting from scratch, there’s no reason to believe you’ll necessarily do a better job than you did the first time. Especially in large, complex systems, it's easy to underestimate the hidden value embedded in the current implementation.

The Illusion of Simplicity

At 1:07, Derek reflects on his early days as a junior developer. Like many others, he often wanted to rewrite large portions of a system simply because he thought the code was bad. But he later realized that this belief often stemmed from not understanding the code, not because the code itself was inherently poor.

He shares a relatable truth:

"Starting something fresh from scratch is easier than really having to dig in, get into the codebase, all the complexity, the edge cases—it’s really difficult."

In essence, what looks like a "tire fire" might just be misunderstood logic wrapped in years of evolution and patching. Developers often confuse unfamiliarity with bad design.

When Rewrites Might Be Justified

Still, Derek doesn’t say rewrites are always bad. Around 1:44, he begins introducing nuance. For teams who’ve been entrenched in the same codebase for years, who understand all the domain complexity and system limitations—rewriting might be a valid option.

"If you've been in a system a really long time... then that's where the nuance comes in. You can say yes, this thing is a tire fire and is holding us back. Maybe it is appropriate to do a rewrite."

"Worse Is Better" and The 80/20 Rule

Derek introduces the concept of “Worse Is Better” at 2:01, connecting it with the Pareto Principle (80/20 rule). He argues that often, 80% of the system’s value comes from just 20% of the codebase. So, when rewriting, the goal should not be to replicate everything, but to focus on the core that truly delivers value.

"There’s a point where less functionality—worse—is the preferable option."

He explains that simplicity and practicality often outweigh completeness. A limited but usable and maintainable system may serve better than a sprawling but hard-to-maintain legacy platform.

Evaluating Cost vs. Benefit

At 2:47, Derek suggests the final call often boils down to cost-benefit analysis. Rewriting for the sake of rewriting is never justified. But if the cost of maintaining old code or being limited by old tech is greater than rebuilding, then the equation may shift in favor of a rewrite.

He references situations where your competitive edge is hindered because you're stuck on outdated platforms or tools. In such cases, the technology gap itself becomes a valid reason to rebuild.

A Lesson from Greg Young

Derek brings up a brilliant post by Greg Young at 3:12, where a prototype that accidentally made it to production was rewritten. The rewrite took 9 months. The outcome?

"After our nine months of beautiful architecture and code work, we were approximately making $10,000 more a month."

Greg concluded that they’d have been better off building 30 new prototypes to test new strategies rather than investing deeply in rebuilding that one. Derek loves this conclusion because it challenges the assumption that technical perfection is always the goal.

Sometimes, software that is “good enough” wins—especially when it's already delivering business value.

The “Old vs. New” Bias

At 4:20, Derek addresses the common mindset that old is bad and new is good. He offers a personal example: he integrates with two third-party services that serve the same purpose. One uses modern JSON and is likely built in Python. The other, surprisingly, returns XML and was probably built in ColdFusion in the 1990s.

"They’re both equivalent. They’re stable. They provide the same value to me and my customers."

This highlights that newer isn't always better. Stability, reliability, and usefulness often matter far more than the tech stack.

Derek’s Personal Rewrite Experience

Derek finally shares his own story at 5:31. He participated in a large-scale rewrite after spending over six years in the original system’s domain. The rewrite took about 14 months, driven mainly by a technology gap that limited the system’s ability to integrate with modern e-commerce tools and online services.

"We really did have to rebuild something new for this purpose."

This wasn’t just a case of "bad code"—the system was fundamentally incapable of evolving, so rebuilding was the only viable path forward.

Final Thoughts

At the end of the video, around 6:11, Derek reinforces that the answer isn’t simply “yes” or “no.”

"I don’t think the clear-cut answer is no. I think you should be cautious in making that decision because context matters, and there's a lot of nuance."

Rewriting legacy C# code might be necessary—but only when the context, domain knowledge, value delivery, and tech limitations all support that decision.

Conclusion

Derek Comartin's video is a balanced, experience-driven take on one of software development’s most debated topics: Should you rewrite legacy code? His advice isn’t dogmatic—it’s thoughtful, grounded, and rich with personal insights.

By reflecting on historical lessons, real-world stories, and the trap of “new is better,” Derek helps viewers develop a mature framework for making one of the most consequential decisions in software architecture.

If you’re facing a similar choice in your own C# project, revisit Derek’s video and weigh your context carefully. Sometimes, legacy code isn’t the enemy—it’s just misunderstood.

Watch more insightful videos on Derek’s YouTube Channel. Visit CodeOpinion.com for more content by Derek.