Live data from Hacker News

Things You Should Never Do (2000)

joelonsoftware.com

11–20 of 85 posts

Re: Things You Should Never Do (2000)

#11
I once rewrote a monstrous app that was in development for 5 years (!), in just one month. In terms of LOC it was 20 times smaller than the old codebase. Had the same functionality and then some more. It had zero bugs in the first release, compared to myriad of bugs in the previous one (mostly multithreading related - yes it's hard).

All I did was, I dumped Microsoft's COM/DCOM and replaced it with REST; also replaced C++ and VB with C#. Totally made sense to rewrite from scratch and it was a big win with absolutely no downsides. Like, no downsides whatsoever because otheriwse the same month I would have spent fixing maybe 4 or 5 multithreading bugs in the old codebase.

Anyway, never say "never do X" because you are most likely wrong.

Re: Things You Should Never Do (2000)

#12
From the three dozen or so previous submissions, the actual discussions seem to be:

2013 https://news.ycombinator.com/item?id=6327021

2012 https://news.ycombinator.com/item?id=3624830

2012 (a bit) https://news.ycombinator.com/item?id=3449953

2009 https://news.ycombinator.com/item?id=608431

Re: Things You Should Never Do (2000)

#13

I'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…

Netscape’s big bang rewrite is in great contrast to the current work on Firefox Quantum. Mozilla is slowly rewriting pieces of the browser in Rust to gain better performance and security.

Re: Things You Should Never Do (2000)

#15
Currently on a project where I find myself thinking a lot about this post. I think a lot of the comments here are missing some of the finer points of this argument. "Rewriting" is not per se the problem, "rewriting from scratch" where a project is effectively put on hold until the rewrite gets done, is the real quagmire. There are legitimate ways of doing a rewrite that don't require boiling the ocean and prevent you from shipping. And I'm sure there are exceptions as well, but as a general piece of advice about software engineering I've found this to have a better shelf life than many other nuggets of advice.

Re: Things You Should Never Do (2000)

#16
post #11

I once rewrote a monstrous app that was in development for 5 years (!), in just one month. In terms of LOC it was 20 times smaller than the old codebase. Had the same functionality and then some more. It had zero bugs in the first release, compared to myriad of bugs in the previous one (mostly multithreading related - yes it's hard). All I did was, I dumped Microsoft's COM/DCOM and replaced it with REST; also replace…

This is my experience too. I rewrite often and liberally, and even switch langs (on the side) to check if it can bring huge gains.

Re: Things You Should Never Do (2000)

#17
post #5

« It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time » With the benefit of twenty years of hindsight, I think the programmers who performed the rewrite in question did a better job than the original Netscape implementation. Come to think of it, I'm typing this message on the direct descendent of that re…

Firefox has less market share today than Netscape did at the time this was written.

Re: Things You Should Never Do (2000)

#18
I 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 coffeescript, but that was apparently unmaintainable after 3 months (!!!). So they rewrote it and then I joined, and it apparently made it to 6 months. Then we tried to rewrite it in TypeScript and React which blew 10 man weeks away before we abandoned it. And then he tried to do TypeScript and Angular again but it never launched.

Meanwhile, after the React debacle, I learned my lesson and focused on rewriting and rearchitecting the old code to follow more modern Angular practices (1.5 components and such), and suddenly the code didn't seem so unworkable anymore! Quality improved and features were added that made it a very popular internal site, still in use 3 years after I left that team.

So I agree, I think you should always try to improve what you have instead of starting over. (If only our UX designers would go for incremental improvements too...)

Re: Things You Should Never Do (2000)

#19
Max's answer to the interview question "What is the most terrible code that you ever encountered, and what was your approach to refactoring it?" is relevant here.

In his book "Code Simplicity", Max has a checklist (summarized in point 4 of https://techbeacon.com/app-dev-testing/rewrites-vs-refactori...) -- and that's the checklist referred to in the InfoQ interview.

Re: Things You Should Never Do (2000)

#20
post #5

« It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time » With the benefit of twenty years of hindsight, I think the programmers who performed the rewrite in question did a better job than the original Netscape implementation. Come to think of it, I'm typing this message on the direct descendent of that re…

Firefox has less market share today than Netscape did at the time this was written.

There is a few more competitors today, though.
Post reply on HN