Things You Should Never Do (2000) • Hacker News Board

Re: Things You Should Never Do (2000)

#71

Post by perl4ever » Sat, Jul 04, 2020, 1:10 AM UTC

gfodor wrote: post #26

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…

>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

The implication is that is can be non-obvious if something is potentially that sort of project, as it originally was a large undertaking. I mean, you can assume it's a fake story, but they said it wasn't originally a one person, one month thing.

I don't know that it implies the person who rewrites something is a super-genius, it's just that sometimes a new perspective or tools allow a really amazing improvement.

Re: Things You Should Never Do (2000)

#72

Post by perl4ever » Sat, Jul 04, 2020, 1:12 AM UTC

insertnickname wrote: post #65

jonnycat wrote: post #56

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, e…

Refactoring is different from rewriting.

I think the above implies that it is different, because it is a subset?

Re: Things You Should Never Do (2000)

#73

Post by atsaloli » Sat, Jul 04, 2020, 1:30 AM UTC

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

Here is the link to the InfoQ interview: https://www.infoq.com/news/2018/01/q-a-max-kanat-alexander/

Re: Things You Should Never Do (2000)

#74

Post by entha_saava » Sat, Jul 04, 2020, 3:18 AM UTC

hn_throwaway_99 wrote: post #55

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…

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…

> Actually, the more experience I get, the more I think Joel was wrong.

There is no black and white in software. Joel writes from a viewpoint that's not always applicable to all of us.

Re: Things You Should Never Do (2000)

#75

Post by focus2020 » Sat, Jul 04, 2020, 4:22 AM UTC

Is Joelspolsky overrated ? There is no public code available to verify his competency like JohnCarmack. His writings are more about marketing and general technical knowledge. In my opinion he is overrated.

Re: Things You Should Never Do (2000)

#76

Post by natmaka » Sat, Jul 04, 2020, 6:16 AM UTC

Having the developers of an existing code rewrite it using a much newer language & environment they master, with the existing code working rather adequately (but hard to extend and with mediocre performances)... is pleasant and useful.

Having a smaller and under pressure team of newcomers w/o any knowledge of the underlying concepts tackling a rewrite while trying to understand and fix a clunky existing code is an ordeal.

Re: Things You Should Never Do (2000)

#77

Post by tdeck » Sat, Jul 04, 2020, 7:00 AM UTC

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…

There's a running joke at Google that each internal tool has two versions: an old one that's deprecated and not maintained, and a new one that's being written and not ready. So I don't think these rewrites necessarily persist because they're being done well.

I keep seeing the same optimistic failure mode over and over again at each employer. It's just too tempting to rewrite, say, the SDK package deployment system rather than trying to understand and fix up the messy old Python that some past engineers left behind. And it'll only take three or four months! A year later the messy old Python with unfixed buts is still the only option because the rewrite isn't ready, and the rewrite consumed all the resources that would've been used to fix bugs.

Re: Things You Should Never Do (2000)

#78

Post by goto11 » Sat, Jul 04, 2020, 9:47 AM UTC

GuB-42 wrote: post #68

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…

Rewriting because it is messy will almost never work. Rewriting because there is a fundamental problem with the code base may be worth it. Problems can include: - lack of parallelism, designed with single core CPUs in mind - lack of security, software was designed for single user, offline operation turned multi-user and online - "wrong" optimizations, for example relying on a lot of precomputation when people now wan…

If the code is reasonable well designed (low coupling, separation of concerns and so on) then architectural changes can be introduced by refactoring. I can't imagine an architectural change which will require every single line of code to be rewritten in a realistic application. Most likely there will be large chunks of complex business logic which is largely unaffected by the architectural change.

But migrating away from an obsolete platform probably do requires a massive rewrite. Even then it might be possible to port (rather than rewrite) large chunks.

Re: Things You Should Never Do (2000)

#79

Post by goto11 » Sat, Jul 04, 2020, 9:55 AM UTC

Wowfunhappy wrote: post #53

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.

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.

That is not what Joel means by rewriting from scratch. NextStep was not written to replace Mac OS, it was just later adapted into that purpose. It is a completely different scenario.

Re: Things You Should Never Do (2000)

#80

Post by citrin_ru » Sat, Jul 04, 2020, 10:50 AM UTC

It is hard to defend position "never rewrite" (because sometimes rewrite is an optimal strategy), but I see where it comes from: 1. Most programmers when they encounter legacy code have a strong desire to rewrite it from scratch. Especially when it uses language/framework they don't know well. 2. They significantly underestimate the cost of a rewrite and either it takes much more time than estimated or a new system implements a small fraction of old features and/or re-introduces problems fixed in an old system long time ago.

It a cognitive bias and we can try to compensate it. Though like with any biases - usually you can see it in others, but cannot correct own behavior.