Lessons From Six Software Rewrite Stories

Lessons From Six Software Rewrite Stories

Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading! binspamdupenotthebestofftopicslownewsdaystalestupid freshfunnyinsightfulinterestingmaybe descriptive 106779908 story Lessons From Six Software Rewrite Stories (medium.com) Posted by msmash on Friday February 22, 2019 @02:16PM from the closer-look dept. A new take on the age-old question: Should you rewrite your application from scratch, or…

Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

binspamdupenotthebestofftopicslownewsdaystalestupid
freshfunnyinsightfulinterestingmaybe
descriptive

106779908
story


Software

Programming


Lessons From Six Software Rewrite Stories (medium.com)






Posted
by

msmash

from the closer-look dept.

A new take on the age-old question: Should you rewrite your application from scratch,

or is that “the single worst strategic mistake that any software company can make”

? Turns out there are more than two options for dealing with a mature codebase. Herb Caudill:

Almost two decades ago, Joel Spolsky excoriated Netscape for rewriting their codebase in his landmark essay Things You Should Never Do . He concluded that a functioning application should never, ever be rewritten from the ground up. His argument turned on two points: The crufty-looking parts of the application’s codebase often embed hard-earned knowledge about corner cases and weird bugs. A rewrite is a lengthy undertaking that keeps you from improving on your existing product, during which time the competition is gaining on you.



For many, Joel’s conclusion became an article of faith; I know it had a big effect on my thinking at the time. In the following years, I read a few contrarian takes arguing that, under certain circumstances, it made a lot of sense to rewrite from scratch. For example:
Sometimes the legacy codebase really is messed up beyond repair, such that even simple changes require a cascade of changes to other parts of the code. The original technology choices might be preventing you from making necessary improvements. Or, the original technology might be obsolete, making it hard (or expensive) to recruit quality developers.



The correct answer, of course, is that it depends a lot on the circumstances. Yes, sometimes it makes more sense to gradually refactor your legacy code. And yes, sometimes it makes sense to throw it all out and start over. But those aren’t the only choices. Let’s take a quick look at six stories, and see what lessons we can draw.

I am more bored than you could ever possibly be. Go back to work.

Working…

Read More