Live data from Hacker News

Things You Should Never Do, Part I (2000)

joelonsoftware.com

61–70 of 104 posts

Re: Things You Should Never Do, Part I (2000)

#61
post #41

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.

He makes an exception for open source projects. But a from scratch rewrite is one factor that killed Netscape. Wonder how many thousands of hours were burned on xul at a critical moment.

Re: Things You Should Never Do, Part I (2000)

#63
post #54
post #37

Earlier 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…

Do you have any examples of type two code you could link to? I want to see how bad it can get!

Re: Things You Should Never Do, Part I (2000)

#64
post #41

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.

He's giving business advice, and it's hard to argue a success from that perspective.

Re: Things You Should Never Do, Part I (2000)

#65

"As if source code rusted." - Not unless you rewrite in Rust.

I liked a quote from a No Boilerplate video [0] noting how some of the most commonly used Rust libraries hadn't had any git commits in multiple years: "They're not abandoned, they're done."

[0] https://youtu.be/Z3xPIYHKSoI?si=qHLJyUu6yqbIQUr7

Re: Things You Should Never Do, Part I (2000)

#66

My 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

"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)

#67
Rewriting from scratch is harder than it looks, but it all depends on how far you existing software is from your goal. Imagine that what you have is a word processor and you need a web server, surely you would start from scratch. You might say that I chose an absurd example here, but it shows that sometimes what you have is too far from what you need for evolutionary approach.

Re: Things You Should Never Do, Part I (2000)

#68
I think a good reason to start from scratch is when the language/framework/library you used turns out not to be the right tool for the job, or the general approach turns out to have major limitations.

What other good reasons can you suggest to do a rewrite?

Re: Things You Should Never Do, Part I (2000)

#69
A tool I wrote at a previous job was thrown out after a few years of everyday use within the team. The team lead had noticed that my 300 or so lines of code was unnecessarily complex and could be replaced by ten lines of $TEAM_LEADS_FAVORITE_LANGUAGE. So it was.

Every 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)

#70
I enjoy coming back to re-read this article every few years, because it's one of the rare things that I continue to agree with every time.

Joel 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.

Post reply on HN