Am I wrong in understanding that this rewrite is what produced Gecko, which is still one of the top browser engines a quarter of a century later? I really think Joel called this one wrong.
Things You Should Never Do, Part I (2000)
61–70 of 104 posts
Re: Things You Should Never Do, Part I (2000)
#62Re: Things You Should Never Do, Part I (2000)
#63Earlier quoted context omitted.
Weird to suggest that a veteran of the industry might not have seen "really bad code". I cannot imagine that's true.
I think there's two kinds of bad software The first kind was written by people who know about software, has some attempt at following some conventions, variable names, etc. etc. It's not "clean and shiny", but you can see someone tried . Like if a bunch of first year apprentices built a house. They tried their best, and often did a half reasonable job - at least for a first timer. Plenty of companies are using this k…
Re: Things You Should Never Do, Part I (2000)
#64Am I wrong in understanding that this rewrite is what produced Gecko, which is still one of the top browser engines a quarter of a century later? I really think Joel called this one wrong.
Re: Things You Should Never Do, Part I (2000)
#65"As if source code rusted." - Not unless you rewrite in Rust.
Re: Things You Should Never Do, Part I (2000)
#66My guess at the problem: we all feel a sense of relief when the codebase gets smaller, but making an existing, working codebase smaller is really, really hard work. Deleting it and starting over front loads all the reward
Except that you then have nothing that actually runs. So yes, no more bad code, no mess. But also no good code, except the theoretical possibility for shiny new good code.
Refactoring is usually the way to go. Can be painful as well, when you are in the middle of it and not sure if it works out (I am in the middle of it, while also switching to a different graphic engine, but I finally see the light) - but mostly you still have something that actually works. And then you can incrementially improve on it. Seperate things that should be seperated - remove things nobody uses anymore (tricky and hard to be sure). And rewrite parts, that need a clean rewrite.
With my limited energy now (or my more realistic conception of my limited energy) - that process is way more rewarding for me, than giving in to the illusion that if I just could do it from scratch, it will be all beautiful.
Re: Things You Should Never Do, Part I (2000)
#67Re: Things You Should Never Do, Part I (2000)
#68What other good reasons can you suggest to do a rewrite?
Re: Things You Should Never Do, Part I (2000)
#69Every few weeks someone came to me complaining that something didnt work in "my" tool. Thanks to git I could port the old, working code over to the new tool almost every time. Eventually the 10 lines grew to a few hundred again.
Re: Things You Should Never Do, Part I (2000)
#70Joel mentions the "build one to throw away" mantra, and notes that it can be dangerous, but I'd go further with that: assume the "prototype" you build is going to be the product, and it will never get thrown away and rewritten. Because that's often what ends up happening, and you (and your colleagues) will be much happier working over the next many months or years inside a project where there was at least some thought given to architecture and abstractions when it was started.
The only time where I think a rewrite might be warranted is if you, no matter how hard you profile and work on it, have realized that the framework (or even language runtime/interpreter) you have built on is just not going to give you the performance you need. Even then, you should really be sure that you can't optimize it better, even if that means digging into the framework you're using to make changes. (Digging into the language runtime or interpreter might be a step too far, though, depending on the circumstances.)
Ok, I guess there's one more time: if the architecture of the code is just so completely wrong that you can't add new features or fix issues anymore, and your velocity completely drops to zero. And you are pretty sure that starting from scratch would get you to feature parity faster than embarking upon a series of gigantic refactors. But even then, I think most people underestimate how long that rewrite will take.
But otherwise... nah, it's probably not worth it, unless you're doing it on your own time, as a toy project, for learning or just fun. I might take an old personal project written in C and decide to rewrite it in Rust because I'm sick of C, and just don't care to work on it anymore, even though there are more things I want to do with that project. Now, I'm not saying that's necessarily a good reason to do it, but if I have no professional obligations around that code, it's my prerogative to spend my time however I want.