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

31–40 of 85 posts

Re: Things You Should Never Do (2000)

#31

Post by dlbucci »

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

I completely agree. On my next app, I was forced to use AngularJS (in 2017, somehow), but did get to use TypeScript (which is somewhat hobbled by having to use Angular templates), and this is exactly what we're doing now: rewriting components one-by-one in React. I love refactoring and React is much nicer, so I'm having fun with it :)

Re: Things You Should Never Do (2000)

#32

Post by barrkel »

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…

If you can rewrite in the style of Ship of Theseus, and get a higher quality result, sure.

But if the architecture is wrong, a piecewise rewrite to a new architecture is very tough.

Re: Things You Should Never Do (2000)

#33

Post by bluetwo »

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…

I think a big reason people opt to re-write is a lack of desire to understand the problem as a whole and belief that anything overlooked will get fixed in production. I agree we need to be suspicious of these intentions.

Not to brag, but I recently spent a week re-writing some software I developed over 5 years (thanks covid), and it runs 100x faster. No joke. Better code, better SQL, better indexing, less list manipulation. 100x faster.

Re: Things You Should Never Do (2000)

#34

Post by sukilot »

bluetwo wrote: post #33
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…

I think a big reason people opt to re-write is a lack of desire to understand the problem as a whole and belief that anything overlooked will get fixed in production. I agree we need to be suspicious of these intentions. Not to brag, but I recently spent a week re-writing some software I developed over 5 years (thanks covid), and it runs 100x faster. No joke. Better code, better SQL, better indexing, less list manipu…

That's great work but anything you can do in a week and then throw away if it turns out bad is hardly a risky rewrite.

Re: Things You Should Never Do (2000)

#35

Post by [deleted] »

goto11 wrote: post #29
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…

[deleted]

Re: Things You Should Never Do (2000)

#36

Post by sukilot »

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.

But the market share was lost to a "rewrite" by a competitor.

Re: Things You Should Never Do (2000)

#37

Post by adrianmsmith »

goto11 wrote: post #29
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…

> But long before the rewrite project achieve feature parity with the original, it is already marred by the same issues that motivated the rewrite.

I think there are definitely counter-examples. Can you imagine using an OS in 2020 based on incremental improvements in Mac OS System 9, or Windows ME. Or browsing using a browser based on incremental improvements in Netscape 4.7?

Re: Things You Should Never Do (2000)

#38

Post by Wowfunhappy »

goto11 wrote: post #29
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…

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 was written, the world had insufficient hardware to make multi-tasking practical. It was not designed for networking, because the internet mostly did not exist at the time. It was not designed for security, because computers were a less important target for criminals, and no internet meant far fewer exploit vectors.

All of these features were post-facto bolted onto Mac OS, and the result was an unstable mess. It was ultimately a full OS rewrite that fixed the platform.

---

I'll make a separate case too, for a rewrite I wish would happen: it's all well and good for Slack to build their client in Electron as a small startup that needs to experiment and iterate quickly. However, Slack is now a reasonably-sized public company, and they (should) have a stable product that will not undergo rapid changes.

Now would be an excellent time for Slack to rewrite their client to be a native app on each of the major platforms. They have the resources to create a snappy, performant app that more customers will enjoy using.

Re: Things You Should Never Do (2000)

#39

Post by alex_young »

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…

Google tends to rewrite without all of the features. I guess you can get a way with that if you’re Google.

Re: Things You Should Never Do (2000)

#40

Post by ChicagoDave »

There's a Domain-Driven Design pattern that encapsulates this entire problem. First, never even think about rewriting an entire system. You will likely fail. Not because you're not smart and capable, but because the business won't be patient enough to allow you to do it properly. And they'd be right not to be patient. They have things to sell and customers to support...today.

That's why Eric Evans came up with the Autonomous Bubble pattern. You rebuild features one at a time and connect them to the old code through anti-corruption layers and translation layers. Over time, the older code will be set aside. In a year or two, the plug will have naturally been pulled on all of the older code.

So there's some truth to Spolsky's 2000 blog post. But it's not smart to maintain older code forever either. You have to be careful, thorough, and use the right tools.

Post reply on HN