I think rewriting a project is an endless curse.
Things You Should Never Do (2000)
61–70 of 85 posts
Re: Things You Should Never Do (2000)
#62Always important to mention the alternative, a "Strangler Fig Application", also known as the strangler pattern.
Re: Things You Should Never Do (2000)
#63I completely agree! Throwing away your code and starting over is failing to atone for the sins of the past, and I feel like it prevents you from learning or growing as a programmer. That's why I don't think I'll ever rewrite something from scratch again. To me, this was nowhere more obvious than from my old co-worker who was constantly trying to rewrite the internal site we worked on. First it was angular and coffees…
Rewriting anything complex and actively used from scratch is not a good idea and the problems have been hashed out may times. Having said that, angularjs and coffescript is a terrible software stack in a dead ecosystem, the best course of action is probably incremental rewrite - React is really good at that because it starts out as a small rendering library and you can incrementally replace stuff like routing etc.
For that example, I would just use Decaffeinate to migrate to ES6, upgrade to TypeScript + AngularJS 1.5+ best practices as OP did, and then follow the official AngularJS -> Angular migration path.
Considering they're two entirely different frameworks, Google did a good job creating a usable compatibility layer. This allows a relatively painless "ship of Theseus"-style transition where you have a combination of Angular and AngularJS components interacting with each other, until eventually it's just Angular components and you can drop AngularJS from the build.
Re: Things You Should Never Do (2000)
#64I'm digging through some legacy code, feeling better about it after reading this.
Re: Things You Should Never Do (2000)
#65Refactoring code is a continuum, from "let's do nothing" (0%) to let's rewrite the whole damn thing" (100%). There's a whole spectrum in between. While I'm a "never say never" kind of guy, I do think many well-intentioned engineers make a leap to the 100% solution too easily. There are lots of other tools in the toolbox that can de-risk the process, like becoming more service oriented, implementing facade patterns, e…
Refactoring is different from rewriting.
Re: Things You Should Never Do (2000)
#66Earlier quoted context omitted.
The more experience I get, the more I think Joel was right. Developers want to believe rewrite-from-scratch can succeed because green-field development is easier and more fun than slowly refactoring inscrutable legacy code. But long before the rewrite project achieve feature parity with the original, it is already marred by the same issues that motivated the rewrite. Because the dysfunction which led to the original…
I think I mostly agree with your take, but if I could defend the counterargument for a moment, there exist stronger cases for a rewrite than "we're smarter than those other guys." Namely, what happens if your requirements have fundamentally changed? Classic Mac OS was written at a time when computers had kilobytes of memory and black and white graphics. It was not designed for multi-tasking, because at the time it wa…
"what happens if your requirements have fundamentally changed?" That's not a rewrite, that's a new program with the same name
Re: Things You Should Never Do (2000)
#67I'm a big fan of Joel Spolsky's earlier blog posts, but to be honest, I don't think this piece has aged well. If anything, I'm more of the opinion now that you should almost always plan to do a rewrite, eventually. Lots of big companies successfully rewrite stuff all the time. Google is fairly well known for having rewritten large, critical pieces of their codebase over the years. If anything, what should be warned a…
The more experience I get, the more I think Joel was right. Developers want to believe rewrite-from-scratch can succeed because green-field development is easier and more fun than slowly refactoring inscrutable legacy code. But long before the rewrite project achieve feature parity with the original, it is already marred by the same issues that motivated the rewrite. Because the dysfunction which led to the original…
> if that is the case, you should be smart enough to fix the mess.
The GEOM subsystem is FreeBSD is an example though that sometimes the world changes in a way that you can't accommodate and you have to go do a big bang reset.
Because of that, FreeBSD has a much nicer set of methods for dealing with disks and hotplugging and resizing ... while Linux is still all very ad hoc.
Re: Things You Should Never Do (2000)
#68I'm a big fan of Joel Spolsky's earlier blog posts, but to be honest, I don't think this piece has aged well. If anything, I'm more of the opinion now that you should almost always plan to do a rewrite, eventually. Lots of big companies successfully rewrite stuff all the time. Google is fairly well known for having rewritten large, critical pieces of their codebase over the years. If anything, what should be warned a…
The more experience I get, the more I think Joel was right. Developers want to believe rewrite-from-scratch can succeed because green-field development is easier and more fun than slowly refactoring inscrutable legacy code. But long before the rewrite project achieve feature parity with the original, it is already marred by the same issues that motivated the rewrite. Because the dysfunction which led to the original…
Rewriting because it is messy will almost never work.
Rewriting because there is a fundamental problem with the code base may be worth it.
Problems can include:
- lack of parallelism, designed with single core CPUs in mind
- lack of security, software was designed for single user, offline operation turned multi-user and online
- "wrong" optimizations, for example relying on a lot of precomputation when people now want to change everything on the fly and modern computers allow it if the software is properly designed
- relying on outdated tech, like Flash
None of the previous points involve bad design, but things change, including user expectations. For now, security is a big one. It wasn't a big deal back then, for example, in a game console, a buffer overflow in a game would just cause a crash and piss off the player in some extremely rare case. Now because your console is online and so is your bank, the same relatively harmless bug on the same game can be used to siphon your bank account.
Re: Things You Should Never Do (2000)
#69Earlier quoted context omitted.
I think I mostly agree with your take, but if I could defend the counterargument for a moment, there exist stronger cases for a rewrite than "we're smarter than those other guys." Namely, what happens if your requirements have fundamentally changed? Classic Mac OS was written at a time when computers had kilobytes of memory and black and white graphics. It was not designed for multi-tasking, because at the time it wa…
"what happens if your requirements have fundamentally changed?" That's not a rewrite, that's a new program with the same name
What happens is that you write the first version, and then the requirements fundamentally change (or you learn that your requirements were fundamentally wrong) but it happens gradually and you change and change the old version. It's now mostly meeting the new set of requirements, but has a bunch of cruft from what it used to do.
Throwing that away and writing something to support the new set of requirements is a rewrite.
I take no position, here, on whether it should be done.
Re: Things You Should Never Do (2000)
#70I think saying "you should never rewrite code from scratch" is a bit too dogmatic. There's a cost and risk tradeoff. I think people underestimate the cost of a rewrite (Due to ego or NIH or yak shaving), but I don't think it's never the answer. Sometimes the language is so old it's cripplingly expensive to hire programmers in. Sometimes the code is deeply tied to a hardware architecture that is extinct. Sometimes the…
I hear you.
But I think that dogmatically saying "You should never rewrite code from scratch" is just useful enough to catch the vast majority of instances when you should not rewrite code from scratch.
I'm willing to be called out for being totally wrong for my dogma in the rare instance that the application should be rewritten from scratch.
Every project I have ever joined on, there has been someone who wants to start fresh. There have been a lot of projects. There was one such instance where it was a good idea.