3 ms·

> Adapting mature software to new circumstances tends to take more time and effort than writing new software from scratch. Counterpoint: rewriting your code fr

> Adapting mature software to new circumstances tends to take more time and effort than writing new software from scratch. Counterpoint: rewriting your code from scratch is the worst mistake you can make. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

knightofmars 8y ago
It's not that simple, as most things in reality never are. For example, "Spoiler alert: They rewrote Basecamp from scratch and it turned out great. It took around a year, and new signups doubled immediately following the release of Basecamp 2." https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22 https://medium.com/@herbcaudill/lessons-from-6-software-rewr...
- mark-r 8y ago
  The key to making this work was to keep the old product around, so the rewrite didn't have to duplicate everything the old one did. That both cuts down the amount of effort and insulates you from the undocumented behavior that Joel writes about. If something about the new product doesn't meet your expectations, just keep using the old one.
jasode 8y ago
>Counterpoint: rewriting your code from scratch is the worst mistake you can make. Joel Spolsky's essay is more about rewrites of "ugly" code. E.g. Fix the disorganized code by gradually refactoring into cleaner modules over time instead of a total blank slate rewrite. In contrast, this Geoff Greer essay is about paradigm-shifting software architectural changes which by their nature, are very difficult to retrofit into an old existing code base. For these, it's often easier to start coding with a "blank slate" rewrite. As examples Geoff's category of rewrites (new architecture paradigm) vs Joel's category (unhygenic code cleanup), we can look at Joel's ex-employer Microsoft: - SQL Server database diverged from original Sybase code and rewrote the engine. One of the architecture changes was switching from page locks to row-level locks - C# compiler completely rewritten from C++ code base to C# codebase. One architecture change was "compiler exposed as a libary service" instead of being the closed "black box" that was assumed by the C++ code. - operating system: MS Windows NT as a blank slate operating system instead of gradually extending old 16-bit DOS code or 16-bit Windows 1.0 code. One motivating architecture change was the new 32-bit protected mode on the newer Intel 286 & 386 chips. Another factor was the switch from "cooperative multitasking" to "preemptive multitasking".
- thunderbong 8y ago
  Thank you for putting that so clearly and succinctly. Somehow, I always felt uncomfortable reading Joel's article because I had never seen spaghetti code on large code bases. I now realize that it is because I've been using open-source code bases for quite some time and that is probably the reason why. Recently however I saw some enterprise in-house code and that's when everything fell into place!!
- gwern 8y ago
  And it's worth noting that Spolsky left MS & wrote that essay well before MS had its "come to Jesus" moment when it came to security. A fanatical emphasis on backwards compatibility & avoiding rewrites was not helpful for avoiding that crisis.
aaaaaaaaaaab 8y ago
>rewriting your code from scratch is the worst mistake you can make Yes, rewriting your code is usually a bad idea. Rewriting others' is a different story.
mark-r 8y ago
I had the misfortune of living through a rewrite like that. Even though we were able to adapt large portions of the existing code it still took twice as long as expected. The result was so buggy that we took the unprecedented step of mailing out replacement CDs unsolicited to all registered product owners once the bugs were fixed.
jacquesm 8y ago
There's no black and white here. Yes, rewriting your software from scratch is the worst mistake you can make. Most of the time. Except for those cases where it is actually the right decision. Good luck figuring out up front which one is the situation you are in.

knightofmars 8y ago

It's not that simple, as most things in reality never are. For example, "Spoiler alert: They rewrote Basecamp from scratch and it turned out great. It took around a year, and new signups doubled immediately following the release of Basecamp 2." https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22 https://medium.com/@herbcaudill/lessons-from-6-software-rewr...

mark-r 8y ago
The key to making this work was to keep the old product around, so the rewrite didn't have to duplicate everything the old one did. That both cuts down the amount of effort and insulates you from the undocumented behavior that Joel writes about. If something about the new product doesn't meet your expectations, just keep using the old one.

jasode 8y ago

>Counterpoint: rewriting your code from scratch is the worst mistake you can make. Joel Spolsky's essay is more about rewrites of "ugly" code. E.g. Fix the disorganized code by gradually refactoring into cleaner modules over time instead of a total blank slate rewrite. In contrast, this Geoff Greer essay is about paradigm-shifting software architectural changes which by their nature, are very difficult to retrofit into an old existing code base. For these, it's often easier to start coding with a "blank slate" rewrite. As examples Geoff's category of rewrites (new architecture paradigm) vs Joel's category (unhygenic code cleanup), we can look at Joel's ex-employer Microsoft: - SQL Server database diverged from original Sybase code and rewrote the engine. One of the architecture changes was switching from page locks to row-level locks - C# compiler completely rewritten from C++ code base to C# codebase. One architecture change was "compiler exposed as a libary service" instead of being the closed "black box" that was assumed by the C++ code. - operating system: MS Windows NT as a blank slate operating system instead of gradually extending old 16-bit DOS code or 16-bit Windows 1.0 code. One motivating architecture change was the new 32-bit protected mode on the newer Intel 286 & 386 chips. Another factor was the switch from "cooperative multitasking" to "preemptive multitasking".

thunderbong 8y ago
Thank you for putting that so clearly and succinctly. Somehow, I always felt uncomfortable reading Joel's article because I had never seen spaghetti code on large code bases. I now realize that it is because I've been using open-source code bases for quite some time and that is probably the reason why. Recently however I saw some enterprise in-house code and that's when everything fell into place!!
gwern 8y ago
And it's worth noting that Spolsky left MS & wrote that essay well before MS had its "come to Jesus" moment when it came to security. A fanatical emphasis on backwards compatibility & avoiding rewrites was not helpful for avoiding that crisis.

aaaaaaaaaaab 8y ago

>rewriting your code from scratch is the worst mistake you can make Yes, rewriting your code is usually a bad idea. Rewriting others' is a different story.

mark-r 8y ago

I had the misfortune of living through a rewrite like that. Even though we were able to adapt large portions of the existing code it still took twice as long as expected. The result was so buggy that we took the unprecedented step of mailing out replacement CDs unsolicited to all registered product owners once the bugs were fixed.

jacquesm 8y ago

There's no black and white here. Yes, rewriting your software from scratch is the worst mistake you can make. Most of the time. Except for those cases where it is actually the right decision. Good luck figuring out up front which one is the situation you are in.