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.
Things You Should Never Do, Part I (2000)
31–40 of 104 posts
Re: Things You Should Never Do, Part I (2000)
#32Meh. 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.
Re: Things You Should Never Do, Part I (2000)
#33Re: Things You Should Never Do, Part I (2000)
#34Code 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.
What people rewrite is not really bad code, it's just middling annoying muck code.
Re: Things You Should Never Do, Part I (2000)
#35Related: 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)
Re: Things You Should Never Do, Part I (2000)
#36Earlier 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
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)
#37Code 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.
Re: Things You Should Never Do, Part I (2000)
#38I 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)
#39I 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)
#40I 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…
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.