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

41–50 of 85 posts

Re: Things You Should Never Do (2000)

#41

Post by acqq »

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…

It's about even more than that: it's about the complexity.

There's an inherent complexity in the problem being solved.

And there is an "accidental complexity" in the implementation of the solution.

Throwing away everything, people typically believe that they can avoid handling a lot of the "inherent complexity." But typically there is a good reason why the inherent complexity was addressed in the previous version of the program, and there's a big chance that the new "from the scratch" designers will have to relearn and rediscover all that, instead of transforming the already existing knowledge that is encoded in the previous version.

For anybody interested in the topic, I recommend the number of case studies presented in:

https://www.amazon.com/Search-Stupidity-Twenty-Marketing-Dis...

"In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters"

See about new rewrite of Wordstar simply not having the printer drivers that the previous had, and also other features people already expected, leading to Wordstar's demise.

Or what Zawinski's names "Cascade of Attention-Deficit Teenagers" (search the internet for that, the link here wouldn't work!)

"I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short."

"It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?"

Or an interview with Jamie Zawinski from Siebel's "Coders at Work."

https://www.amazon.com/Coders-Work-Reflections-Craft-Program...

... "even phrasing it that way makes it sounds like there’s someone who’s actually in charge making that decision, which isn’t true at all. All of this stuff just sort of happens. And one of the things that happens is everything get rewritten all the time and nothing’s ever finished. If you’re one of those developers, that’s fine because there’s always something to play around with if your hobby is messing around with your computer rather than it being a means to an end — being a tool you use to get whatever you’re actually interested in done."

If one is able to cover all the complexity, and it is not destructive to the goal, the rewrite is OK. Otherwise, one should be critical to the ideas of rewrites as they could be potentially secretly motivated by simple (jwz again): "rewriting everything from scratch is fun (because "this time it will be done right", ha ha)"

Re: Things You Should Never Do (2000)

#42

Post by allenu »

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 agree. With the right tools, expertise, and design, rewriting is absolutely an option. I've learned over the years that it's often better to just rewrite some crufty, old code entirely than to try to understand the old code to patch it up. This requires a very good understanding of the requirements, which have often changed from the original code, to come up with a better design for the present needs.

Of course, this doesn't apply in all cases, but "never rewrite" is a limiting strategy.

Re: Things You Should Never Do (2000)

#43

Post by goto11 »

Wowfunhappy wrote: post #38
goto11 wrote: post #29

Earlier quoted context omitted.

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

But didn't Apple actually attempt a full rewrite of the Mac OS which eventually failed? So instead they bought an already working OS and adapted it for their purpose.

Re: Things You Should Never Do (2000)

#44

Post by ChrisMarshallNY »

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…

It's a lot easier to do now, because we are in a dependency-based system. We can often replace tens of thousands of lines of legacy with a single call to a SaaS API.

Of course, T.A.N.S.T.A.A.F.L, so caveat emptor. Needless to say, picking the right dependency is a big deal.

Re: Things You Should Never Do (2000)

#45

Post by BoiledCabbage »

adrianmsmith wrote: post #37
goto11 wrote: post #29

Earlier quoted context omitted.

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?

But again in the Windows ME vs WinNT/Windows2000 case it wasn't a re-write. It was improving an existing product and using it in a consumer space.

Re: Things You Should Never Do (2000)

#46

Post by ChrisMarshallNY »

goto11 wrote: post #43
Wowfunhappy wrote: post #38

Earlier quoted context omitted.

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

But didn't Apple actually attempt a full rewrite of the Mac OS which eventually failed? So instead they bought an already working OS and adapted it for their purpose.

Oh yeah. I remember that clearly. It was Copland- er, MacOS 8.

What a cluster----. Back then, crashes would result in a special kind of debug screen called MacsBug[0].

When you walked into their "release-ready, hands-on lab," almost every screen was displaying MacsBug.

The change didn't actually happen until NextStep became Cocoa.

I was also at a Microsoft "Longhorn" prerelease event. They were showing "live code demos," but you could clearly see the presenter quitting Director, when they were done with their demo.

That became Vista, another famous success story (but at least, it did ship).

[0] https://en.wikipedia.org/wiki/MacsBug

Re: Things You Should Never Do (2000)

#48

Post by goto11 »

adrianmsmith wrote: post #37
goto11 wrote: post #29

Earlier quoted context omitted.

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?

These are hypotheticals, but isn't the Blink engine incremental improvements all the way back to KHTML? It has been more successful than Mozilla.

Re: Things You Should Never Do (2000)

#49

Post by katzgrau »

Joel classic, and it always reminds me of times I've seen this happen again and again years after it was written. I don't think I've ever seen a full rewrite bring all of its heralded benefits. I'm sure there are some people who have. There always end up being things the old system did better, and sometimes you wind up with the old and new systems running in parallel because end users need to switch back and forth until v2 is finally mature (it seemingly never finally matures).

That said, I'm in favor of a rewrite when the use cases for the platform have diverged so significantly that you essentially have to bend it in half to make it do the thing that users want it to today. That is, as some point the core use cases have changed, perhaps via a pivot, and you need to build a product that is essentially new as compared to the old.

Regardless, the cases where I've seen a rewrite take place are when the engineers are young, talented, and enthusiastic about new tech and the engineering manager doesn't want to piss them off so they let the devs play (most of them will be off to other jobs in 2-3 years leaving behind a system that is debatable as ugly and busted as the old).

Re: Things You Should Never Do (2000)

#50

Post by goto11 »

ChrisMarshallNY wrote: post #46
goto11 wrote: post #43

Earlier quoted context omitted.

But didn't Apple actually attempt a full rewrite of the Mac OS which eventually failed? So instead they bought an already working OS and adapted it for their purpose.

Oh yeah. I remember that clearly. It was Copland- er, MacOS 8. What a cluster---- . Back then, crashes would result in a special kind of debug screen called MacsBug[0]. When you walked into their "release-ready, hands-on lab," almost every screen was displaying MacsBug. The change didn't actually happen until NextStep became Cocoa. I was also at a Microsoft "Longhorn" prerelease event. They were showing "live code de…

From wikipedias Copland article (https://en.wikipedia.org/wiki/Copland_(operating_system)):

"The Copland development effort is associated with empire-building, feature creep, and project death march. In 2008, PC World named Copland on a list of the biggest project failures in IT history."

Post reply on HN