Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things You Should Never Do (2000)

joelonsoftware.com

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Things You Should Never Do (2000)

#21

Post by larsenwolf »

tedunangst wrote: post #17
mjw1007 wrote: 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.

An anecdote I know, but I recently converted from Chrome to Firefox and am actively distancing all of our technology within away from Google.

Re: Things You Should Never Do (2000)

#22

Post by michaelcampbell »

MarkSweep wrote: post #13
hn_throwaway_99 wrote: post #9

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.

The reason is less important than the methods.

Re: Things You Should Never Do (2000)

#23

Post by rubber_duck »

dlbucci wrote: post #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 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.

Re: Things You Should Never Do (2000)

#24

Post by myth2018 »

Agree that you should never rewrite from scratch. However, I believe that almost 100% of rewrites are not actually from scratch: even if not a single line is reused, there will be plenty of experience serving as a foundation.

I'm not implying that's always the case. Besides, in some cases, past experience is deliberately not taken into account -- I'm aware of a handful of systems written in procedural languages which performed not that great and were replaced by naive object-oriented implementations. Went really bad.

Re: Things You Should Never Do (2000)

#26

Post by gfodor »

mojuba wrote: 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…

I think this advice is not relevant if you are on a project where it's feasible for a single developer to re-write it in a month. Burning a month on a failed re-write is certainly worth the risk if you take a run at it.

For projects where there are several devs going to be working on the re-write for a long time, it almost certainly is a sign that the 'legacy' code has way more knowledge embedded in it than it might seem. Having been on the death march of a re-write before I think the signs are usually obvious when you're in one scenario or the other.

Re: Things You Should Never Do (2000)

#27

Post by the-dude »

michaelcampbell wrote: post #22
MarkSweep wrote: post #13

Earlier quoted context omitted.

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.

The reason is less important than the methods.

I can't imagine this to be true.

Re: Things You Should Never Do (2000)

#29

Post by goto11 »

hn_throwaway_99 wrote: post #9

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…

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 code turning into a mess have not been addressed.

"But we are smarter than those other guys who wrote this mess" - if that is the case, you should be smart enough to fix the mess.

Re: Things You Should Never Do (2000)

#30

Post by justin_oaks »

I've heard such thoughts expressed as "Evolution, not Revolution". You evolve (refactor) your old app into the new one, rewriting parts of it at a time.

Several comments have already expressed that they've rewritten projects successfully. I've also evolved several projects successfully too. One of the benefits of the evolution approach is that when old bugs resurface, they're less likely to show up all at once since you only changed part of the application. Also it should be easy to compare the code with the bug to the previous code without the bug because it mostly similar.

There are times when an application is beyond repair and a rewrite is necessary, but I see those times as the exception rather than the norm.

Post reply on HN