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

51–60 of 85 posts

Re: Things You Should Never Do (2000)

#51

Post by sgerenser »

BoiledCabbage wrote: post #45
adrianmsmith wrote: post #37

Earlier quoted context omitted.

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

But Windows NT itself was a rewrite not an evolution of Windows 3.1.

Re: Things You Should Never Do (2000)

#52

Post by HenryBemis »

ChicagoDave wrote: post #40

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

> They have things to sell and customers to support...today.

Deau ex Agile.. knock out one "thing" at a time and let's keep loading the backlog for the next features/etc to be upgraded/rewritten. Tbh in banking I see very few rewrites, most banks (that make their own applications) don't fix it unless it breaks down. They only bother in massive upgrades where modules are rewritten, or an application is replaced one module at a time.

Re: Things You Should Never Do (2000)

#53

Post by Wowfunhappy »

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.

Well, as I'm thinking of it NextStep was still effectively a "rewritten from scratch" OS—it just happened to get written outside of Apple.

Re: Things You Should Never Do (2000)

#54

Post by zelphirkalt »

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…

There are other arguments for rewrites usually though.

Some of the problems came only to light, because the original software was written and showed weaknesses. Of course afterwards one always knows more.

Then there is the reason of software often not perfectly matching your use-case and you could have better, specialized for your use-case software. You might also have other ideas about how extensible and modifiable your software should be. There really is a lot of software out there, that barely works for its use-case. If you are asked to extend that, good luck with that, without introducing new bugs, due to inflexible design.

So there are very valid reason for rewriting and often you do know better, how to write the software for your own use-case.

Re: Things You Should Never Do (2000)

#55

Post by hn_throwaway_99 »

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…

Actually, the more experience I get, the more I think Joel was wrong. Like anything in software, I've had the experience that there are good ways and bad ways to do rewrites. Start with the reasoning for doing it:

Bad reasons: "The code is messy", "It's written in language foo while all the cool kids are using language bar these days", "It's slow".

Good reasons: "The architecture is too tightly coupled now and it won't scale without untangling major pieces anyway", "The lack of our forward velocity is directly related to problem XYZ in the code, and here is how a new architecture would fix that."

In other words, I feel like I can sniff out bad rewrites now, which are generally lack a sense of focus and a true, enumerated list of problems with the current code base. Good rewrites have clearly delineated benefits that the rewrite will bring, stuff that brings measurable value, and show that the rewrite will bring things better and more cheaply than what's possible with the current codebase.

Re: Things You Should Never Do (2000)

#56

Post by jonnycat »

Refactoring code is a continuum, from "let's do nothing" (0%) to let's rewrite the whole damn thing" (100%). There's a whole spectrum in between.

While I'm a "never say never" kind of guy, I do think many well-intentioned engineers make a leap to the 100% solution too easily. There are lots of other tools in the toolbox that can de-risk the process, like becoming more service oriented, implementing facade patterns, etc., which all in some way or another work towards a "rewrite" usually without ever rewriting everything.

Sometimes you get the benefits of the 100% solution with 25% of the work, and without most of the risk. "Yeah, that part of the codebase is old and crufty, but we never have to touch it because it Just Works and there's no point in rewriting it."

Re: Things You Should Never Do (2000)

#57

Post by fnord77 »

we have a data processing system in production that, for various reasons, will not scale horizontally without major work to the open source framework we're using.

Nobody has any appetite to fix the semi-abandoned framework, so if we want to process additional data from bigger workloads, we really have no choice but to rewrite our system.

Joel's right - there's a lot of pitfalls. We tried this once and it was a failure. Our 2nd attempt is going much better, though.

Re: Things You Should Never Do (2000)

#58

Post by jjtheblunt »

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…

Your last sentence made me think humorously of Fermat's Last Theorem, and 350 years of grad students trying to prove it...so ironic and in that way funny.

Re: Things You Should Never Do (2000)

#59

Post by wolfgke »

sgerenser wrote: post #51
BoiledCabbage wrote: post #45

Earlier quoted context omitted.

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.

But Windows NT itself was a rewrite not an evolution of Windows 3.1.

Windows NT wasn't a rewrite of Windows 3.1, but an attempt of Microsoft to create a modern workstation OS that is in a completely different product category than DOS/Windows 3.1.

Re: Things You Should Never Do (2000)

#60

Post by emn13 »

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

My impression: it's still easier than a rewrite. People always underestimate a rewrite, because they only consider the complexity they can think of, which is generally only the tip of the iceberg. I've been on projects where even though people nervously joked about the dangers of rewrites they still underestimated the costs. Bonus points if afterwards people scratch their head thinking "where the heck did all that time go"?

I think rewriting to a new architecture piecemeal is probably easier than in a big bang - assuming the thing is at all complex and you can't actually understand all of it at once. The difference is more one of perception. It's easier to see the costs of the Frankenstein architecture than the rewrite, so we overestimate the costs of the former and underestimate the latter.

The real case for a rewrite is if you honestly think all that old stuff really has mostly just sentimental value; i.e. that it's OK to break all kinds of workflows because there are enough alternatives. If you can sell actual users on relearning all their habits, you can get away with a lot.

Post reply on HN