Live data from Hacker News

Things You Should Never Do, Part I (2000)

joelonsoftware.com

31–40 of 104 posts

Re: Things You Should Never Do, Part I (2000)

#31
post #30

Earlier quoted context omitted.

Other way around in my estimation.

I've read every line of a 300,000 line web application in less than a year working at a company. I doubt I could write that many lines of code in that amount of time.

What language do you use? In UI you can reach that 300k loc quite quickly.

Re: Things You Should Never Do, Part I (2000)

#32
post #6

Meh. I rewrilote our backend in about 3 month, and in the end of rewriting another service. All good so far! Sometimes stuff is broken so badly you better start over

Sure do that for a few lines or even tens of thousands of lines. Don't do that for millions of lines without real serious consideration, and I'd add, a good reading of Joel's post.

Well, millions of lines, you should just create a new company.

Re: Things You Should Never Do, Part I (2000)

#34
post #17
post #14

Code may not rust, but it may be broken out of the gate. Joel and others may not have seen really bad code, but it exists. All of us have written code in our careers that we're not proud of. And there's code written by people who are proud of everything they've written or code written by people who just don't care. These two are usually good candidates for rewrites.

You are right. But IMO you're still missing his main point. His thesis is in that case, to rewrite ONLY THE REALLY BAD CODE. There is not team that is 100% bad so you don't need a full rewrite of 100% of the code base.

That's exactly it - really bad code can be refactored piece by piece.

What people rewrite is not really bad code, it's just middling annoying muck code.

Re: Things You Should Never Do, Part I (2000)

#35
post #4

Related: Things You Should Never Do, Part I - https://news.ycombinator.com/item?id=31122975 - April 2022 (7 comments) It’s harder to read code than to write it - https://news.ycombinator.com/item?id=31117277 - April 2022 (2 comments) Things You Should Never Do (2000) - https://news.ycombinator.com/item?id=23725867 - July 2020 (83 comments) Things You Should Never Do, Part I (2000) - https://news.ycombinator.com/item?…

And a bit earlier: https://news.ycombinator.com/item?id=6327021 - Sept 2013 (154 comments)

Whoa I missed that and several others - not sure what happened there. Added above now. Thanks!

Re: Things You Should Never Do, Part I (2000)

#36
post #13
post #10

Earlier quoted context omitted.

50-100K LOC are less than the amount of code for the build system in a couple of projects I worked on.

Then you've got bigger problems

Oh, for sure. Giant C++ projects have lots and lots of issues.

Yet, they do useful work and just abandoning them in-place and rewriting them from scratch is rarely a good solution for these problems.

Re: Things You Should Never Do, Part I (2000)

#37
post #14

Code may not rust, but it may be broken out of the gate. Joel and others may not have seen really bad code, but it exists. All of us have written code in our careers that we're not proud of. And there's code written by people who are proud of everything they've written or code written by people who just don't care. These two are usually good candidates for rewrites.

Weird to suggest that a veteran of the industry might not have seen "really bad code". I cannot imagine that's true.

Re: Things You Should Never Do, Part I (2000)

#38
Whenever I come across these Nevers and Always, I look for the exceptions.

I mostly agree with the sentiment. Slow, incremental changes, whether to code or even a website's style. Mostly. But sometimes you run across code so malign, so neglected, so undocumented, uncommented, twitchy, troublesome, inexplicable, that the risks of the Second System Effect are worth it.

Really, I think the crucial point comes when your system is a kind of obelisk. You tiptoe around it, make offerings, but you don't know how to appease its wrath. It's like the weather.

Then it is time.

Re: Things You Should Never Do, Part I (2000)

#39
> they think the old code is a mess. . . . they are probably wrong. The reason that they think the old code is a mess is ... It’s harder to read code than to write it.

I suppose I think the reason people think code is a mess is because it _is_ a mess. Just yesterday I saw a team decide to override $PATH in 50 separate files because they didn't understand how to package a python library. (I'm not innocent in crazy stuff either, we're all human).

My experience is that rewrites happen when a team doesn't have anything clear to do instead, so it's more like "teams/businesses with no clear objectives" struggle rather than inherently rewrites.

Re: Things You Should Never Do, Part I (2000)

#40

I think people tend to want to rewrite software for the psychological break from the old, bad and ugly thing they don't want to have anything to do with anymore. It is so easy to think "If only I could start everything from scratch, life will be so beautiful and I will be so successful and everybody will be happy. I will fix all the problems of the current codebase and people will forever sing songs about how amazing…

> developers not really understanding

Rewriting software is an excellent way to gain such understanding. I only understood what GNU autoconf was doing when I was in the middle of rewriting its core functionality in pure GNU make.

And who knows? You might actually make a better wheel against all odds.

Post reply on HN