Matt's Homepage

#42 – Never rewrite your software from scratch.

I have referred this article to many a developer that has become enamored with the idea of ‘scrapping it all and rewrite from scratch’. It’s a phase that almost every young developer goes through when they come into an existing codebase. Senior engineers have a duty to explain why re-writing isn’t always an option and how to make that choice. Refactoring, or a organized series of refactor stories, however, is almost always a better answer.

As Joel tells us, rewriting from scratch is one of the worst strategic mistakes and likely one of the larger technical mistakes you can make. He wrote this in the first dot-com boom in 2000, but it’s even MORE relevant today in the fast paced entrepreneurial world where time to market is one of the critical factors to the success of your idea. Even to the point that speed is the ONLY critical factor and the only requirement is that you just need to get it working once.

Joel Spolsky knows his stuff. He’s a chairman, founder, developer and entrepreneur that created Trello, Glitch, FogBugz, worked at Stack Overflow, Microsoft Excel, and numerous other accolades.

Give his excellent article a read.

Further musings

Are there legitimate times you need to re-write from scratch? Possibly, but I think they are rare and getting rarer – refactoring is almost always a better solution unless you are radically changing the direction of a product. A good lead should take a step back from the desire for the cleanest code and ask what’s the right decision given the entirety of my engineering and business constraints.

Legitimate cases I can think of: radical change of direction in your product, dependent hardware/OS goes end of life, security issue in component you can’t update, or due to licensing issues. Then you are likely facing a legitimate re-write – MAYBE. And that maybe gets bigger each year.

In the case of end-of-life hardware, one notices that compute overhead is increasing every year. Many realize now that simply virtualizing and/or emulating old hardware is MUCH better, faster, and cheaper than re-writing/porting. Apple is demonstrating this with Rosetta 2 on their new M1 chips. Intel did this with it’s mobile emulator. There’s literally hundreds of game console emulators. Why rewrite when you can simply write one emulator and statistically end up with far few bugs, far better scaling of impact, and hugely faster time to market for a whole product line?

Virtualization has also become a first class solution for OS/software stacks that no longer have support. One should ask if they can simply slap the component into a virtual machine. This might work if the system has an issue like an unpatchable security hole or you need new functionality on a system with no more support. You might be able to wrap the component in a virtual machine and solve the security or feature issue in the host and pass through existing behavior. This keeps production going and you can replace the system at your leisure.

Licensing issues can be the one real killer. This is why it’s so critical to evaluate usage licenses strategically before you first pick up a SDK/piece of software and use it. Properly evaluating the IP and licensing of your core packages is a critical first architecture task. There is no greater disaster than finding out a critical package has a business model breaking licensing requirement right before you ship – and this is one case in which you almost guarantee a painful rewrite/replacement of key functionality.

If you find out you have to do the rewrite, his points about rewriting are true for these forced cases too. You’re going to spending a TON of time and money to get back to where you already are today. Strategically, this is going to crater all forward momentum of your business and opens you to now being in a race with any competitor also starting from scratch. Even worse, once you have your rewritten solution, you’re also going to have to fix bugs and edge cases you had already solved, or never even knew about since they were covered by the old architecture’s inherent properties (this is another reason why people that argue “the code is the documentation” are patently wrong).

So, to add to his article, I’d add emulation and virtualization as further solutions to avoid a rewrite.

3D printed houses aren’t anything new; but still on the cusps of practicality. Hadrian X has created a robot that can cut and lay the bricks of a 3 bedroom 2 bath house in 2 days; working around the clock and in all weather conditions. Limitations still appear to be that this just places bricks – it doesn’t seem to do electrical, plumbing, ducts, initial foundation/etc. But this is just one more step forward into complete automation of construction. Likely something we’ll see by the end of our lifetimes.

File this in a ‘with a grain of salt’, but odds are good there is some truth behind this research. It would be great if benchmarking tools could detect the age of your GPU and see if they can corroborate this claim.

Palit Microsystems, a Taiwan-based graphics card manufacturer, is reporting that graphics cards in near constant use on massively compute intensive crypto currency mining degrade in performance by about 10% each year. Most cards in these environments run 24/7 and often on extremely compute heavy workloads. Proper cooling, power delivery, accelerated silicon aging, or a host of other factors could be leading to this

The caveat empeter here is that Palit is a manufacturer of new graphics cards, and gets no money from the resale market. So, they do have an interest in encouraging users to buy new cards. Too bad it’s impossible to get them…