Anti-patterns: Rewriting Software

Home » Blog » Business » Anti-patterns: Rewriting Software

It’s one of those fallacious patterns in software development that though well-known to cause trouble without creating any significant benefit unfortunately ever seems to truly go away: The Software Rewrite.

In general, software developers tend to not particularly like working on old – or legacy – code, especially if it’s not been written by themselves or if they feel that due to aspects like time and budget constraints they didn’t have the opportunity to get the software architecture right from the get-go. Then on the other hand, there’s this – perfectly understandable yet to an extent detrimental – fascination with the new and shiny: Everybody loves starting and working on something new. Even if it’s not for the romantic notion that every beginning has something magical about it, starting with a clean slate allows you to work without seemingly hampering constraints imposed by existing projects. Working on a greenfield project often enables you to work with new technologies and learn something in the process.

Joel Spolsky of Stack Overflow, Microsoft Excel and Trello fame (as credentials in the software development world go you probably can’t score any higher than that) famously decried rewriting software as something you should never do citing Netscape as a prime example of how to ruin your company by trying to reproduce your existing software product without providing any additional benefit to your customers.

The gist of his argument is adequately summarised in this quote:

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.


You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

Legacy code isn’t just cruft that accumulated over the years for no good reasons. In part, it probably is. For the most part, however, existing code enshrines your business rules, processes and the – often otherwise implicit – knowledge of your company. In other words: It’s what makes your company special. It’s a competitive advantage that helps you succeed on the market rather than hold you back. If you ponder rewriting your software, you might just as well consider starting your business from scratch, which clearly in just about every case wouldn’t make sense. Why would you give up a (hopefully) thriving business for the lofty notion that everything will be better once you’ve tossed your tried and tested processes out of the window and replaced those with largely unproven ones? Gradually transitioning from existing ways of operating and continually adapting to new situations is crucial. You have to be changing and growing in order to continue being successful. That doesn’t mean foregoing previous knowledge, though. That knowledge is what allows you to make educated decisions about the present and the future in the first place. Legacy code is just that: Knowledge that has you make informed decisions in lieu of guesses.

Software developer Umer Mansoor has a more recent take on this matter. However, though in general he arrives at the same conclusions he admits there are situations when a rewrite perhaps does make sense. Though I still side with Spolsky in that I think you should never completely rewrite you software, it’s worth noting that “the developers didn’t like the architecture” certainly is none of those situations.

Leave a Comment


I agree

Privacy Preference Center

Strictly necessary

These cookies are necessary for the site to function.

PHPSESSID: Preserves user session state across page requests.



Google Analytics statistics cookies help us to understand how visitors interact with our websites by collecting and reporting information anonymously.

You can opt out of Google Analytics tracking by clicking on the opt-out link in the banner below.

_ga: Registers a unique ID that is used to generate statistical data on how the visitor uses the website.

_gat: Used by Google Analytics to throttle request rate.

_gid: Registers a unique ID that is used to generate statistical data on how the visitor uses the website.

ga-disable-UA-25326096-9: Stores whether you have opted out of Google Analytics tracking.



These cookies are used for storing your privacy settings

gdpr%5Bprivacy_bar%5D: Privacy settings have been reviewed.

gdpr[consent_types]: The uses of your data you agreed to.

gdpr[allowed_cookies]: The cookies you allowed us to set.

gaoop_hide_info: Set if you agreed to our use of Google Analytics.



We use Wordfence to secure our website against hacking attempts:

Cookies set by the Wordfence plugin
To help you understand which cookies the Wordfence plugin sets, when installed on your WordPress site, we have provided the guide below. Wordfence currently sets three cookies and we explain what each cookie does, who will have the cookie set, and why the cookie helps secure your site.

What it does: This cookie is used by the Wordfence firewall to perform a capability check of the current user before WordPress has been loaded.

Who gets this cookie: This is only set for users that are able to log into WordPress.

How this cookie helps: This cookie allows the Wordfence firewall to detect logged in users and allow them increased access. It also allows Wordfence to detect non-logged in users and restrict their access to secure areas. The cookie also lets the firewall know what level of access a visitor has to help the firewall make smart decisions about who to allow and who to block.

What it does: This cookie is used to notify the Wordfence admin when an administrator logs in from a new device or location.

Who gets this cookie: This is only set for administrators.

How this cookie helps: This cookie helps site owners know whether there has been an admin login from a new device or location.

What it does: Wordfence offers a feature for a site visitor to bypass country blocking by accessing a hidden URL. This cookie helps track who should be allowed to bypass country blocking.

Who gets this cookie: When a hidden URL defined by the site admin is visited, this cookie is set to verify the user can access the site from a country restricted through country blocking. This will be set for anyone who knows the URL that allows bypass of standard country blocking. This cookie is not set for anyone who does not know the hidden URL to bypass country blocking.

How this cookie helps: This cookie gives site owners a way to allow certain users from blocked countries, even though their country has been blocked.


Close your account?

Your account will be closed and all data will be permanently deleted and cannot be recovered. Are you sure?