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

Re: Things You Should Never Do (2000)

#81

Post by citrin_ru » Sat, Jul 04, 2020, 11: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…

> the 'legacy' code has way more knowledge embedded in it than it might seem.

Cannot agree more, but when knowledge embedded only in the code and not in comments/commits and documentation it is a problem even if you don't plan for re-write.

It is very disappointing to hear from otherwise good programmers statements like: "good code doesn't need comments (and my code is good)". As a result we have code where some line can captures hours of research and/or discussions, but there are no comments and commit logs are too brief. After a year even an author usually cannot say why it was done this way.

Re: Things You Should Never Do (2000)

#82

Post by goto11 » Sat, Jul 04, 2020, 2:07 PM UTC

dllthomas wrote: post #69

yCombLinks wrote: post #66

Earlier quoted context omitted.

"what happens if your requirements have fundamentally changed?" That's not a rewrite, that's a new program with the same name

What happens is that you write the first version, and then the requirements fundamentally change (or you learn that your requirements were fundamentally wrong) but it happens gradually and you change and change the old version. It's now mostly meeting the new set of requirements, but has a bunch of cruft from what it used to do. Throwing that away and writing something to support the new set of requirements is a rewr…

I would recommend just removing the cruft rather than throwing everything away. But cruft should really be removed continuously.

Re: Things You Should Never Do (2000)

#83

Post by dllthomas » Sat, Jul 04, 2020, 5:30 PM UTC

goto11 wrote: post #82

dllthomas wrote: post #69

Earlier quoted context omitted.

What happens is that you write the first version, and then the requirements fundamentally change (or you learn that your requirements were fundamentally wrong) but it happens gradually and you change and change the old version. It's now mostly meeting the new set of requirements, but has a bunch of cruft from what it used to do. Throwing that away and writing something to support the new set of requirements is a rewr…

I would recommend just removing the cruft rather than throwing everything away. But cruft should really be removed continuously.

I was merely being descriptive, clarifying that there are not uncommon situations where requirements have changed and yet nonetheless one of your options is aptly termed a rewrite.

If I am to move into making recommendations, then I think the whole thing is ultimately situation dependant, but that your advice is correct for the most common cases.

Re: Things You Should Never Do (2000)

#84

Post by hn_throwaway_99 » Sat, Jul 04, 2020, 7:25 PM UTC

entha_saava wrote: post #74

hn_throwaway_99 wrote: post #55

Earlier quoted context omitted.

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.

> There is no black and white in software.

That is my whole point. The title of the blog post is "Things You Should Never Do", and it highlights "They did it by making the single worst strategic mistake that any software company can make." (emphasis Joel's).

Doing a rewrite may be a horrible mistake, but Joel was just wrong advising no company should ever do it. Lots of companies have done that, quite successfully.

Re: Things You Should Never Do (2000)

#85

Post by gfodor » Sun, Jul 05, 2020, 3:17 PM UTC

perl4ever wrote: post #71

gfodor wrote: post #26

Earlier quoted context omitted.

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…

Yeah I was referring to the posterior - eg if your project could be rewritten by one person in a month (unbeknownst to you beforehand) then the advice is irrelevant. Hence it’s worth attempting a re-write in some cases to determine that, and failing fast.