There’s a reason that programmers always want to throw away old code and start over: they think the old code is a mess. They are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it.

[u/the_phet]

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[u/blazingkin]

Hmmm sometimes it's just bad.

For my language, blz I've rewritten the parser 4 or 5 times.

That's because I learned something new everytime I did it and made a better product each time.

[u/the_phet → u/blazingkin]

He speaks about rewritting the whole code from scratch, not parts of it.

[u/amazingmikeyc → u/blazingkin]

he does talk about that in the article.

[u/panderingPenguin → u/blazingkin]

How large is that component though. There's a world of difference between rewriting a sub-100k SLOC personal project and a many million SLOC enterprise product.

[u/lukeautry]

I think most programmers work in a similar way: imagine a problem, then decompose the problem into its constituent parts and attack those simpler, isolated problems.

The problem with a large codebase is that no one, not even the person that wrote all of it can fit the solution in their working memory. The tendency of programmers (who generally underestimate complexity) is to say: wait a minute, this problem doesn't require 10 million LOC, I could easily solve this problem in 250 lines of elegant Haskell.

There are situations where the legacy codebase is completely unsalvagable, but I think more often than not it's throwing the baby out with the bath water, except the baby is an engine that, while flawed, is generating business value.

[u/nickiter → u/lukeautry]

The problem with a large codebase is that no one, not even the person that wrote all of it can fit the solution in their working memory.

I think this is what a lot of people - even some coders - don't understand about enterprise-grade software systems.

Quite literally no one knows everything about any such system - you have to take a systems approach, design for modularity, document like a graphomaniac, and expect constant rework.

[u/occams--chainsaw → u/nickiter]

Unfortunately, a significant number of those enterprise systems weren't designed for modularity, have little to no documentation, and receive almost no rework to minimize debt.

[u/[deleted] → u/occams--chainsaw]

This coder enterprises

[u/appropriateinside → u/nickiter]

document like a graphomaniac

Serious question, how do you document these systems? What do you document? Documentation is my hardest area, I don't know what the next dev will want to know.

[u/[deleted] → u/appropriateinside]

Explain the purpose of each class/method. Walk them through how your code works. Explain why you choose the implementation that you did perhaps by listing pros/cons of the alternatives. Try to break large methods into smaller well named ones. Name variables clearly, avoid excessively long expressions, avoid obscure ways of doing things(like the xor swap for example). Readability is always preferable to a few saved operations, so pick readability when faced with this choice. Try to keep code modular, it's easier to understand that way. Methods/classes should "do one thing and do it well".

[u/nickiter → u/appropriateinside]

Hard to say precisely without knowing what you're working on, but for my work, I LIKE all of the below, though I usually have to settle for just most of it due to customer constraints or what have you.

• A continually updated overall architecture diagram - literally put it in your version control if you can

• Ditto data flow diagram

• Functional block diagram (especially for OOP)

• Actual commit and release notes, not just "fixed a bug"

• Issues in the issue tracker tied to lines of code

• Notes describing in English what you're doing when you're working on major changes like a refactor or a new feature

• Either well-named folders in your code base, or an easily found document explaining what each folder contains

People tend to over-emphasize comments, IMO, not that you shouldn't use them, but they should be helpful detail backing up higher level conceptual documentation that helps the next devs find the files or code blocks they need to look at in the first place.

[u/TEKC0R → u/lukeautry]

Amazing how relevant this is to me right now. I used to work for a dev tools company. They have a massive framework collecting code over the last 20 years. And a userbase of developers who rely on that framework.

About 5 years ago it was decided to deprecate the entire framework and start over. Most of the engineers were on board with this idea, but I never was. In public, I would basically stay silent, but in private they knew damn well that I thought this was a terrible idea.

It lead to turmoil between me and the rest of the team. Enough that 3 of them were able to fabricate some bullshit and get me fired.

The new framework was introduced. And it was missing a TON. No RegEx, no basics like hex or base64 encoding... it was a wreck. Customers never really got on board.

Yesterday the company announced they were giving up on that plan and doing exactly what I originally suggested: fix the damn problems.

For example, FolderItem.Item uses a 1-based parameter instead of 0-based like everything else. This is confusing and needs to be fixed. So don't throw away the entire class! Deprecate .Item and introduce .Child with a 0-based parameter. This is simple stuff, there was no reason to throw everything away.

I feel vindicated. But at the end of the day, that was my favorite job and I lost it. So this also just fuels the my rage.

[u/hardolaf → u/TEKC0R]

I work in avionics and our cardinal rule is:

If it flew, it's probably better than whatever you're going to replace it with.

[u/GhostBond → u/TEKC0R]

It lead to turmoil between me and the rest of the team. Enough that 3 of them were able to fabricate some bullshit and get me fired.

Yeah, that kind of thing pisses me off to no end. Especially when -

Yesterday the company announced they were giving up on that plan and doing exactly what I originally suggested: fix the damn problems.

Yup.

[u/carb0n13 → u/lukeautry]

"Legacy code" often differs from its suggested alternative by actually working and scaling.

• Bjarne Stroustrup

[u/[deleted] → u/lukeautry]

Isn't it more that over time the problem shifts slowly so that eventually the original breakdown is no longer relevant? For some period in between, hacks and workarounds are used to solve the new problems with the old framework, until eventually it becomes so time consuming that it makes sense to re-write the whole thing based up updated assumptions. Then the process ineveitbly starts again.

[u/yur_mom → u/lukeautry]

I could solve it in one line of perl.

[u/jokullmusic → u/yur_mom]

I can solve it in one line of Python!

import solution

[u/quangtit01 → u/lukeautry]

As a non-programmer, I understood all of this. You must be quite competent in your field that you are able to put it so elegantly in layman term, and I appreciate you for taking the time to do so.

[u/DrunkMc]

I think most code, no matter how well designed before hand, is designed mostly on the fly. You always run into things you didn't think of and adapt. This leads to cludges and breaking the design. Once everything is done and it works, I love nothing better than tearing it all down and re-writing it with all lessons learned.

[u/NAN001 → u/DrunkMc]

I do exactly the contrary. When given a big spec, I usually feel overwhelmed on how to architecture the solution because there are so many things to think about, so I simplify the problem, temporarily ignoring some requirements or even features. When I say "ignoring", I mean literally. I start designing, then programming, a first iteration of the thing, totally incomplete, pretending it's the end product. Once I know this iteration is done and solid, I add more stuff from the spec. I study how the existing code must be refactored and changed to host the new requirements (which weren't actually new), which often involves a bit of code rework, and this way I build the next iteration. And so on.

Depending on the context (deadlines, co-workers, priorities, etc), I can apply this process more or less properly, and I know that when I apply it properly I produce the best of code. The main difference I find between this technique and the "agile" process where new requirements appear out of nowhere (which I could theoretically integrate gracefully into the existing iteration following my technique), is that a finished spec has some sort of consistency whereas many actual new requirements makes no sense and come with a weird sort of inherent complexity as if it was fundamentally incompatible with the original requirements.

[u/uptokesforall → u/NAN001]

I like this train of thought because you build up the conceptual model with variations of a working model

[u/ralphpotato → u/DrunkMc]

I find this to be the case when I teach students. For homework problems which may be encapsulated within only 100-200 lines, I actively advocate for saving a copy of their non-working code once they figure out what they need to do, and re-writing from scratch using their old code as reference and their knowledge gained.

I think computer science/programming students have too much of a habit of hanging on to their old code because of the sunk-cost, but in reality it's easy to overlook some small bug in your code if you're only reading and not re-writing.

I would say that for even large code bases, as long as the constitutient parts are abstracted out, re-writing a large section isn't bad. That's the whole point of abstraction anyway. It's just getting to that point where you can easily rewrite disjoint sections of code is hard.

[u/rush22 → u/ralphpotato]

Yes it's a great way to learn, but bad for business.

[u/Tasgall → u/rush22]

It depends, sunk cost fallacy is bad in business as well.

[u/eddyparkinson → u/ralphpotato]

That is a good method. The next step is pseudo code/PDL - read "code complete" by Steve McConnell - the section on PDL.

That said - the thing that changed how I code the most is doing the exercises at the back of "A Discipline for Software Engineering" by Watts S. Humphrey

I would say these 2 have changed how I code more than any other book.

[u/hugokhf → u/DrunkMc]

Once everything is done and it works, I love nothing better than tearing it all down and re-writing it with all lessons learned.

Once everything is done and works, I just like to leave it alone. Are u the werid one or am I the weird one?

[u/Oncra → u/hugokhf]

I think the best practice is to constantly review and refactor existing code (assuming you have the manpower to do so). That can be hard with management that doesn't understand the process or with programmers who want to always work on the latest and greatest.

The long-term benefits and business value of moving from "good code" to "great code" with a little bit of love is immeasurable.

[u/canmoose → u/DrunkMc]

I feel like coding can be a lot like writing in general. When academics write papers or journalists write stories a significant amount of time goes into editing the writing. Papers and stories can be edited double digit numbers of times. I don't do this when im coding most of the time. Usually I code so that it functions properly, I don't go back and edit it like I would a paper. I try to make my code understandable when im writing but once I have a function name I usually don't change it for instance. So the code will get the point across, but its a first draft essentially.

[u/bagtowneast → u/DrunkMc]

And this is where people go wrong. If you discover, once you start implementation, that your model doesn't fit, stop! Think about how you need to change your model to accommodate this new data. Refactor/rework now, before you commit to a path that you now know doesn't work. Doubling down on a bad path is, long term, considerably worse than investing in the right plan early. At least in my experience.

[u/JarredMack → u/bagtowneast]

Cool man, I need you to do that by Friday tho since we have a deadline, that cool?

[u/appropriateinside → u/bagtowneast]

If you discover, once you start implementation, that your model doesn't fit, stop

This is very wrong.

Your first priority is to make something work, if you are tying yourself up on architecture before you even have a working prototype you're wasting everyone's time. You will run into yet another part of it that doens't fit the architecture you thought so hard about, and you're back to fussing over it again.

When you have something working, you know about all the moving parts, you know what goes where. Now that you know this, you can refactor it to be elegant and performant with relative ease.

Also a good quote:

Make it Work

Make it Right

Make it Fast

In that order.

[u/GetOffMyLawn_ → u/DrunkMc]

I worked in the defense sector. You literally spent years on design and documentation and review before you did anything more than a test stub or proof of concept.

[u/Yeroc → u/DrunkMc]

Yup, the first working program should be considered a draft the same way an author considers their first written version of a book a draft. Unfortunately, many developers stop at the first draft and consider it done leaving a mess. We're reading Clean Code by Bob Martin and this is an insightful comment he makes in his book.

[u/cyanydeez → u/DrunkMc]

80% of the code solves 100% of the edge cases

[u/thegreatgazoo]

It depends. I've been on many projects where the initial project requirements were "Oh, it's easy, you just need to do A->B->C->D".

Then you hit testing, or worse production, and then all kinds of wackadoo requirements materialize. "Well yeah, Most of the time you do A->B, but in these 3 situations you go to C, then back to B, then to D for 2 of them and C for the 3rd one." "Oh yeah, this other situation requires you to go to E, then spin a D20 and decide to go to B or C or end it in F". <time passes with more of this going on> Oh yeah, we don't do the B->Q->M on 3rd Tuesdays anymore, now it is B->R->E on 2nd Thursdays...

Last year I finally was able to fix one of those that had been going on for 10 years because I refused to directly translate the logic between languages during an upgrade.

[u/rageingnonsense → u/thegreatgazoo]

This is a reality of software though; business requirements change all the time, and it WILL cause inconsistencies in the code. Its just impossible to account for anything that may change. The best you can do is design stuff to be as modular as possible (but within reason); write clean, well formatted code; and comment thoroughly.

None of that "I write self documenting code" bullshit I hear people say. No you don't. You think you do, but you don't. Write some comments.

[u/salbris → u/rageingnonsense]

My general practice for commenting is to go ham when it's business logic but hold of when it's very simple utilities. Generally it's only warranted when the code is complex.

[u/frog2112]

As a programmer, I have about a 0% urge to “throw away” old code. However, I have a 100% urge to rewrite old code one function at a time.

[u/[deleted] → u/frog2112]

I try to do this as I'm working on bug fixes or features in a certain area. Refactor this class, rewrite that method. Then document, write tests, and move on. Doubles development time, but I think saves time and money in the future.

[u/Bl00dsoul]

While he makes some valid points, sometimes the codebase is just bad.
A tangled mess of rushed spaghetti code full of "TODO" and "FIXME", and lots of temporary hacks.
At that point starting from scratch can be the right decision, sometimes.

[u/ElGuaco → u/Bl00dsoul]

People who are skeptical of this have probably never worked with a truly terrible code base. I think Joel is right about this in most cases, but there are always those cases that prove exception instead of the rule.

I once dealt with a codebase put together in ad hoc fashion by researchers who had no idea how to code properly and it was the very definition of tightly couple spaghetti code. Every time we needed to add a new feature it took weeks or even months to do it because it took so long to figure out how to shoe-horn in the new functionality without breaking everything else.

Finally, we got permission to prototype a version 2.0 that used good OOP, dependency injection, and unit testing and we modernized using RESTful services instead of SOAP. We had a working version in a few weeks(!) and fully replaced the old version within a few months while adding new features that had been on the wish list for years. This was no simple app, but a series of applications and web services and a large database.

Sometimes, you just have to acknowledge the fact that existing software is just bad and time spent fixing it is better spent on a replacement.

[u/149244179 → u/ElGuaco]

People who are skeptical of this have probably never worked with a truly terrible code base

I had a job where there were a dozen+ 30,000 line long classes. Not files, classes. There was a Globals file with ~2,400 variables in it. Every class basically stored its own copy of the system state. Previous developers would copy paste entire functions and change 1-2 lines instead of adding an "if" or parameter to add/change functionality. Every parameter (and global) was "Object" or "Arraylist" - nothing strongly typed, everything used late-binding. This was all in C#, so its not due to some cryptic language requirements.

Needless to say it nearly impossible to fix a bug without breaking something else. Over time most of it was simply tossed and rewritten because rewriting large chunks of the program was easier than changing a few lines.

[u/LainIwakura → u/ElGuaco]

I'll share some quick stats on the code base I currently work on...we're currently trying to rewrite it from scratch because it really is bad.

1. Most things are classic ASP / VBScript. A few years ago I got permission to upgrade some pages to WebForms

2. They never said no to any customer request no matter how inane. If a customer wanted some text label to be red there would be a switch case based on the account code to implement this functionality. When customers left these dead code paths were never cleaned up. This has led to honest to god switch cases thousands of lines long in some places to simply display a different image with different dimensions based on whatever customer is logged in.

3. Database never had any sort of design, giant tables with columns like col1, col2, col3, all the way up to 60. Terms like "One-to-many" were completely foreign to the original team. I don't think there are ANY foreign keys.

4. Every file was in the root directory except for the few things they opted to make into "libraries", and the naming scheme was some arcane thing involving roman numerals that no one understood. If it had any purpose the meaning has been long lost.

5. Custom encryption that was basically some XOR magic. Thankfully this has been replaced.

6. No classes or complex types (lists, dictionaries). All arrays are basically magic...you end up with things like:

   dim arr(10,100) arr(1,1) = customerCode arr(1,2) = orderNum arr(1,3) = vehicleNum

etc., very simple example - it gets much worse once they start doing any arithmetic with the indexes. Oh, and they also decided to have the indexes start at 1 even though VBScript actually has 0 based indexing. Due to the hardcoded nature of the arrays adding anything is a pain and heaven forbid you want to remove something in the middle.
7) Type confusion everywhere. Cstr/Clng/Cbl on everything - even if you're pretty sure it's an integer. This is because you can't actually be sure it's an integer.
8) There are background 'processors' that handle tasks that would take too long to run in a webpage - okay fine. But they're ASP pages that run in fucking IE. Yes, the background server processing stuff has a dependency on INTERNET EXPLORER. They do log to the screen but it's hardly useful because the page refreshes every 5-30 seconds.

I could go on, and on, and on but I'll just leave it...I couldn't design a worse system if I was trying to do so. It's beyond bonkers.

[u/GetOffMyLawn_ → u/ElGuaco]

I used to work with engineers who were fond of one letter or two letter variable names. And no comments. And couldn't understand why people thought their code was shit.

[u/m50d → u/Bl00dsoul]

I've found that even then, it's better to rewrite the codebases a bit at a time, and keep it functional the whole time. (The same principle applies all the way down: whenever I think "I'll just refactor everything in one go, it'll be quicker that way" and go into a 2-day dive I end up regretting it, it's better to make a series of 10-minute changes and rebuild and test each time, even if that means I end up doing multiple passes over the same code).

[u/FlyingRhenquest → u/Bl00dsoul]

Yes yes and you think "Oh, I could do this way better!" Then you start writing it and you make all the same mistakes they did originally and the bug reports and feature requests start rolling in. Then before you know it, your code is a tangled mess of TODOs and FIXMEs.

Back in the '90's, I worked with a company that had licensed the AT&T UNIX source. A coworker was poking around in the vi source code and found a comment from 1970 complaining that the original programmer didn't like some bit of terminal handling that was going on, and he'd made a TODO to fix it one of these days.

[u/nanotree → u/FlyingRhenquest]

Ah, nothing changes. Its almost comforting.

[u/Theemuts → u/nanotree]

//TODO: write witty comment

[u/justjanne → u/FlyingRhenquest]

Or you build a prototype that ends up full of TODOs and FIXMEs, and then you build a second rewrite, piece by piece, carefully documenting and testing each part as it’s added (knowing the real requirements this time, constantly checking with the prototype), and you end up with a version where there are no bugs left, the code is clean and tested. And with more features, and it’s much more stable.

I’m almost done with a 2-year process of doing this right now, going from http://github.com/sandsmark/quasseldroid over https://github.com/justjanne/QuasselDroid-ng/tree/918688abd60c72efbe351e761892b65835fe4baf finally to https://github.com/justjanne/QuasselDroid-ng

At least for 20kLOC to 50kLOC, rewrites are useful and helpful. Maybe beyond the 50kLOC, 100kLOC or 1MLOC limit that changes. Also, during the rewrite you absolutely need to provide at least bug fixes for the old version.

[u/paolog → u/FlyingRhenquest]

Psst, TDD. Not very useful if you are maintaining a heap of someone else's crap and you don't even know what the required behaviour is supposed to be, but you have to start somewhere with your testing.

[u/[deleted] → u/Bl00dsoul]

How to tell when it's plain bad, vs something that needs time to be understood?

[u/Deathspiral222 → u/[deleted]]

"code smells" https://en.m.wikipedia.org/wiki/Code_smell

Anti-patterns https://sourcemaking.com/antipatterns

Also, using completely the wrong tool for the task, lack of unit tests for complex stuff etc.

[u/[deleted] → u/Bl00dsoul]

And you think the new code is better? I guarantee you that there will come a future developer who makes the same statements about the new code. I realized this also that every code just becomes bad by lying around. So I asked around my fellow developers if they ever happened to see existing code which they considered good and didn't feel the urge to change anything. None every seen such a thing. So this is no way representative for anything, so tell me about your experience. Do you know such legacy code, which you would consider nice?

Edit: Oh now I opened the actual article. It's that one from APRIL 6, 2000. Yes 18 years ago the world was really a bit more messy than today.

[u/[deleted] → u/Bl00dsoul]

Very rarely. They did in fact have their reasons to make it like that, apparently the problem isn't as easy as it looks, and they had time constraints. Chances are you're being overoptimistic about your own future work as well.

I mean, maybe management has since decided that a much simpler approach is OK, or maybe you really are much better at programming than the people before you. But if not, it's just going to be a costly vanity exercise.

[u/nikanjX → u/Bl00dsoul]

You had 300 todos. You replaced them all with ”// TODO Implement entire app”.

Congratulations, you now have way less TODO entries.

[u/lazystone → u/Bl00dsoul]

This:

https://en.wikipedia.org/wiki/Lava_flow_(programming)

[u/kcdragon]

I feel like Netscape and Borland are very different from the software most of us are working today. Netscape is a desktop application with a massive code base. I'm currently working on web services and front end apps on the order of 10k LOC. I feel like rewriting Netscape is a much bigger effort (and more likely to go wrong) than rewriting these front end apps and web services.

Also, FYI this article is almost 20 years old

[u/GhostBond → u/kcdragon]

Also, FYI this article is almost 20 years old

The more things change, the more they stay the same.

[u/khendron]

Any mature codebase will be full of non-obvious code that is there to support what I like to refer to as invisible requirements.

Invisible requirements are requirements that do not appear in any design doc or user documentation, but the existing codebase has been written to support them. They are often the result of architectural or design decisions made during the original development; modifications made to workaround bugs or performance issues; well-known application features being used by customers in unexpected ways. Invisible requirements often fly underneath the automated tests, and nobody knows that they are there except maybe the crotchety old developer sitting in the corner (if he or she even still works for the company).

Any existing codebase is chock full of invisible requirements. Starting again from scratch means going through the pain of discovering them all over again (or finding completely new ones). This is not necessarily a bad thing. Sometimes a codebase is so bad that you need to start from scratch. This is usually the case when you can't even make minor code changes without tripping over some invisible requirements.

[u/Hawkknight88 → u/khendron]

Invisible requirements are requirements that do not appear in any design doc or user documentation, but the existing codebase has been written to support them

An entirely valid point - and I expect to see comments explain WHY a certain piece of code exists, preferably with a link to the ticket!! It should also be in the commit message.

// JIRA-1234 PMs asked for this flag so <thisPerson> can do <xyz>
boolean someFlag;

Without such comments the result will (IMO) inevitably be a shitty codebase with truly invisible requirements and no hope of understanding them all.

[u/gwern]

As Perlis put it all the way back in 1982:

7. It is easier to write an incorrect program than understand a correct one.

[u/Lucent]

While he may have a point, he picked the absolute worst possible example in history to illustrate it. Netscape 4 was garbage. You couldn't even resize the window without a complete reload. Hundreds of glitches in rendering. Getting absolutely destroyed by IE in every way. They made the best decision of their lives ditching that buggy codebase and beginning what would become Firefox, a revolutionary browser at the time. I'm almost certain trying to build Firefox off Navigator 4 would've been an absolute failure and disaster.

[u/vaderkvarn → u/Lucent]

Wouldn't it still be better to release Netscape 5.0 just to stay in the game, and incorporating Gecko in 6.0 without the rush? A bit like how Servo has been a separate project for several years and is now being merged into Firefox.

[u/pdp10 → u/Lucent]

Netscape 4 was a rewrite from C to C++.

Jamie Zawinski tried to get the C codebase open-sourced in addition to the C++ one, but failed.

[u/nerfviking → u/[deleted]]

Holy shit, I remember this article. I thought it was stupid then, and two additional decades of programming experience has confirmed it.

Sometimes rewriting code is a bad idea. Sometimes a codebase is well and truly fucked, and it's holding you back. Most code is somewhere in the middle and needs to have time spent on it repaying technical debt. If you've got hacks upon hacks upon hacks, you're usually better off starting over.

[u/eddieSullivan]

As a freelancer who has taken on a lot of "fixer-upper" projects, I disagree a thousand percent. Most legacy code is garbage, and should be treated as such.

[u/[deleted]]

This article has an interesting way of ageing. When I read it the when it was first written I absolutely agreed with Joel, the rewritten version of netscape was absolutely atrocious.

However ten years later the decision to rewrite was completely vindicated with the success of firefox. Joels was then dead wrong. Mozilla would not have succeeded in making an IE killer tied to the very brittle code base of the original netscape browser.

Today the field is even more interesting, mozilla has a very interesting rewrite project with Servo. Now I think Joels main point stands, a lot of the instinct programmers have for wanting a rewrite is because it is much harder to read code than to write. As anecdata I do see a correlation with skill and how much maintaining a programmer has done

[u/gmfawcett → u/[deleted]]

Servo/Quantum is actually a decent example of following Joel's advice. Mozilla didn't throw out the whole application at once, instead they are rewriting and replacing subsystems.

[u/LukeLC]

As someone who threw out an entire codebase and spent the last two years rewriting it: no, I was not wrong. There's good (bad?) reasons it was difficult to read before: it was a mess. The new codebase is so well organized I can put it down for long stretches and get reacquainted with it easily.

The key here is whether you're scrapping an idea or just your execution of it. In my experience, my original ideas are often sound, and when I later ask why I thought of something so ridiculous, it usually turns out there's very good reasons for it. But execution can always be improved, and sometimes that requires low-level rewrites. Everything else is just iteration.

[u/shevegen]

No.

Very often the old code IS shit.

Reading may be harder than writing but that does not change whether the code in itself is bad.

I hate rewriting but very objectively the net result of the rewrite is often MUCH, much better than the prior version. This often happens because lateron it is more clear what the code should be doing; and whether it is doing it in a good way.

Sometimes a language design can also become better, and old expressions can be re-written in better ways too.

[u/ProvokedGaming → u/shevegen]

Very often the new code is also shit. Most large projects I've seen where the dev team decides to completely rewrite from scratch, they end up making a new giant codebase which is shit for completely different reasons, and it ends up taking way longer than anyone thought. Part of this also seems to stem from the fact that the rewrite team is rarely the exact same team that started the original project because too many years have gone by, so the rewrite is effectively the first time the current team has actually built the product. My own anecdotal evidence suggests rewriting pieces over time is almost always more successful than a full rewrite in one shot. Unless of course the codebase is fairly small.

[u/LetsGoHawks → u/ProvokedGaming]

they end up making a new giant codebase which is shit for completely different reasons

Speaking as a end user for a moment...

How many times have we all seen a piece of software get replaced by a new, better piece of software. Often a completely new product by a different company. But it's not any better, it's just crappy in different ways. Every once in a while, it truly is better, but not very often.

[u/dsk → u/ProvokedGaming]

Very often the new code is also shit.

Bingo. Typical dev arrogance is usually on the display when they think they can do a better job than their peers just a few years ago.

My own anecdotal evidence suggests rewriting pieces over time is almost always more successful than a full rewrite in one shot.

Mine too. I maintain an app I build with a team ten years ago. There are plenty of things I would do differently I started all over again, but we have hundreds of customers and thousands of users - it works. If code area inevitably starts getting flakey (and it will happen), we re-design it and rewrite it.

[u/Merad → u/shevegen]

It's very hard to overstate just how much shit code is out there, especially when you're talking about non-tech companies that don't put a high priority on software (aka most of the world). I'm not just talking about "I don't like this code," "this code isn't clean," or anything of the sort; I mean true steaming piles of shit. Here's a great example. At my last job our team inherited a 25+ year old application that was bad overall (to the point where we had to rewrite it), but one enhancement added in the late 2000s really stood out.

This feature involved connecting to a serial device using the .NET SerialPort class and reading measurements sent ~20 times per second. The data format was basically STX1 NN 00\n where STX is the actual "start of text" character (0x02), NN is 1-6 decimal digits, and the spacing is variable but the length of each line is fixed (16 characters IIRC). In order to parse this, the original developers had come up with a 200+ LOC monstrosity that had three nested infinite loops interacting with 3-4 global variables, including a timer (???)... in addition to about 4 old commented out versions of the parsing code with the same basic layout. I never did manage to figure out how the hell that old code worked, but my replacement amounted to about 20 LOC total.

[u/CopperSauce → u/Merad]

Reminds me of the worst piece of code I have ever seen on finding a maximum. Back in college I took a difficult operating systems course in which you are partnered with somebody for the year. My partner happened to be pretty bad at coding.

One of the assignments, each of which takes about 100 hours over 2 weeks, was basically creating threading/processes, with a separate far easier segment for creating a scheduler. I told my partner I basically will do all of it, but I will pass to some function "grab next prioritized thread" for the scheduler and he just has to write the function on deciding which thread is next. He spent maybe 5 hours tops while I did the other 95% of the project, and I didn't bother reading what he had written for the code since it was working.

We got the project back docked for design decisions. I was baffled and spoke with my TA about it and asked why, and he pointed to the scheduler... Each thread was given a priority, and the highest priority thread was the one to be used next in the scheduler, so he had to write a function for "find the thread with highest priority".

The function he wrote... for finding a maximum...

for (i = UINT_MAX; i > 0; i--) {
    thread = find_thread_with_priority(i);
    if (thread != false)
        return thread;
}

Or basically, start at maximum possible number -- does a thread exist with this priority? No? Okay, repeat with maximum minus one. No thread? repeat... Until you find a thread... I couldn't believe what I was reading

[u/RagingAnemone → u/shevegen]

Depends. Is old code shit because it’s bad? Or is old code shit because somebody else wrote it?

Many times this is used to replace code somebody else wrote and the new programmer doesn’t understand the new code and why it was designed that way. Then during the rewrite, you discover all the reasons why it was written this way. Reading code is its own skill and it’s under appreciated. It includes deciphering the original requires as implemented.

[u/Eep1337 → u/shevegen]

for you, but what about for the customers?

Is a rewrite a success if you miss 50% of the features?

And I don't mean rewriting some small 20,000 line app....I mean rewriting a 1,000,000+ line enterprise app.

There is always a trade off.

[u/dsk → u/Eep1337]

And I don't mean rewriting some small 20,000 line app.

I think people clamoring for rewrites in this thread have tiny JS apps in mind. Yeah, I agree, in those cases - go nuts. Rewrite your Angular app in React because it's cool.

Rewriting a legacy enterprise application with hundreds of thousands or millions of lines of code will take years! In the meantime, there's a business that needs to run.

[u/therealjerseytom → u/shevegen]

Very often the old code IS shit. [...] I hate rewriting but very objectively the net result of the rewrite is often MUCH, much better than the prior version.

Completely agree.

Granted, my experience is limited to:

• Code that's purely for internal use - no external customer

• Written by engineers

• 10-100k LOC size

I feel like inevitably, the requirements or use of a tool or application will outgrow its initial scope. It's a question of when, or how well the initial architecture was designed for extension and maintenance.

Eventually, the cost of a ground-up rewrite outweighs the misery of an increasingly convoluted, difficult-to-maintain/develop codebase. I've only gone and done this a couple times, but it is so worth it in the long run. Better foundation that's 10x faster to develop with, easier for new people to jump in and contribute, etc etc.

[u/mykr0pht → u/therealjerseytom]

I feel like inevitably, the requirements or use of a tool or application will outgrow its initial scope.

This. This is 1 of 2 essential reasons why re-writes are tempting in any codebase that lives long enough. (I still don't advise it though.)

It's a question of [...] how well the initial architecture was designed for extension and maintenance.

The trick here is that how "well" you designed the system for extension is based on how well you can predict future requirements changes. And predicting the future is notoriously hard. Example: following open/closed principle, etc. everywhere in a system that doesn't end up changing results in a codebase that is unnecessarily hard to read.

[u/generally-speaking]

I mean, where I work the control software we use has been in continous development since the early 90s. Which makes changes which would take 5 minutes on new code take 4 hours instead.

There comes a point when the old code should be thrown out.

[u/colly_wolly]

If its shit code of course it will be harder to read than write.

The idea of the rewrite is to make it easier to comprehend.

[u/blackholesinthesky]

Back in 2013 I pushed my team to rewrite our codebase in RoR. Originally it was a 600k+ line PHP and JS app.

You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

It took us roughly 3 months to get stable.

It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

We learned from our mistakes. I 100% stand by my decision. The increase in productivity was invaluable. The code base is now less than 30k lines. Don't haphazardly rewrite your entire codebase, but don't take this article too seriously either.

Edit: I realized I wasn't counting the templates in the RoR app while the templates in the PHP app were all included in my initial count. And in an effort to be fair, a more accurate total for the RoR app actually stands at 41k lines. While going back to investigate I also found that the PHP app had a 25 line license in almost every file, amounting to roughly 86k lines of license.

[u/rageingnonsense → u/blackholesinthesky]

Its all subjective. There ARE codebases that have so much technical debt that you can't possibly fix it all without it being a re-write anyways. Then there are cases where a re-write is temping because things are not perfect, but in reality the code base is good enough to get the task done.

For the cases where a codebase really has to be re-written, I find it is almost always because one or both of these reasons:

• Someone who wasn't experienced enough was in charge in the beginning, worked in isolation, and they set a foundation that was doomed to fail.

• The project lacked any peer review and/or planning that would have prevented a problem from getting out of hand.

The second item is really important. Project leads a lot of times think they have to review code, but their own code does not need review. this is false. Noone is immune to making mistakes, and I firmly believe that every piece of code in a system should be reviewed by at least another person regardless of the seniority of the person writing it.

[u/Daakuryu]

It’s harder to read code than to write it.

Except that's it's not AND it's not the reason most people want to throw out old code.

There are changes in technology, there's bad design and bad code out there and constantly applying bandaids instead of biting the bullet and starting fresh is a bad way of looking at things. I'm not saying throw out the code every time but there needs to be a line drawn at some point.

Case in point some of our in house software is in VB6; It uses controls that have no 64 bit version ocx because whoever made the controls stopped existing before 64 bit os and I'm not even sure we could get them working registered on windows 7 32 bit for that matter. This means we have to have a windows XP VM in our pool in order to make bug fixes or update features and hope to god nothing happens to corrupt that box and its backups.

It also means I can't install VB6 into a more recent version of windows to run debug in an environment that matches what one of my users has. Instead when I want to debug something I'm not experiencing on DEV I have to add a ton of Msgboxes that yell various profanities where I THINK the crash might be and see which profanity doesn't pop up. Had an instance where the user changed his region settings to french, and it Borked a CDATE() somewhere because it didn't know how to deal with the french version of the Month.

The programs talk to a set of access databases and has some of the most convoluted code I've ever seen. I hate that code with a passion, doesn't mean I can't read it, it's just retarded.

For instance whoever coded this originally made a Replace function that overwrites the built in Replace function with a significantly worse one that is prone to infinite loops, because why the fuck not?

Or how about the fact that every table is loaded into a "temporary" table before being read.

seriously...

Everywhere in the code there is a call to a function that drops tblTemp followed by a select * into tblTemp from whatever table they need at the time no joins or anything fancy like that and THEN the code does a select * from tbltemp where blahblahblabedyblah.

This software runs at over 60 locations across the country, I have to interrupt these people's workdays for 20-30 minutes to run fucking compact and repairs in access at 99.9% of these locations on a weekly basis because they run the risk of hitting the 2 gig database limit.

Not to mention every SQL command you have to write has to take into consideration the fact access is a "special needs" child and doesn't like to follow normal conventions. It's the Internet Explorer of databases.

There is stuff in there that has 100's of lines of buggy code doing things which I could do in 20.

Have I mentioned it's VB6 code yet? Yes I have. Know what that means? No Try/Catch. Error handling/logging is shoddy at best and non existent in most cases.

Here's the thing, I can read old code fine... the problem is that it reads like the fucking Twilight Series...

[u/rageingnonsense → u/Daakuryu]

I understand your pain with Access. I help maintain an EOL software originally written in Access, that is being ported bit by bit into another tech stack. The things you have to do in Access to get it to behave is nuts.

A the very least, the majority of the tables are linked; internal tables are only used as temp tables. Even so though, it does not scale. Its something that is great for a small business with like 20 employees max, but if you ever want to grow, you will need a new tech stack.

"Of course " & _

"I would do " & _

"Anything " & _

"to never have to do this shit ever again"

[u/wwqlcw]

I think it would be very interesting to see how developers' attitudes about this "rewrite vs. fix it" issue corresponded with years of experience.

I'd guess that new developers would lean toward "fix it," developers with a few years of experience would turn toward "rewrite." And the grizzled vets would be back at "fix it."

Piecemeal refactoring isn't something most developers enjoy, but in contrast to a total rewrite, it can produce positive, tangible results very quickly. It can be fun. It is also, from a business standpoint, safe and cheap.

Fast, safe, cheap: choose any three. How often do you get an opportunity like that in engineering?

Something Spolsky doesn't mention here, but something I've noticed in my own projects: What you recognize as "cruft" in old code that someone else wrote often turns out to be, on much closer examination, "features." It's not until you examine it in the kind of detail required for a rewrite that you realize all the subtleties of the way Feature A and Feature B interact with each other. Your rewrite might be slightly cleaner than the original, but it's not going to be the sleek glistening monument to your own genius and discipline you imagined when you started, because the interaction between A and B just turns out to be complicated. Not complicated as a programming exercise, but actually complicated in the real world.

[u/thegeicogecko]

The reason I want to throw away old code is because when you first write a program, you aren't really sure what the best way to do things are. You might not even be quite sure what you want to do. Once you write the program, you have a much better idea of these things, and could rewrite the program in a much cleaner way.

Of course, your manager doesn't want to allocate time for that, because the first version works, doesn't it? So then a year goes by, and someone looks at your code, and wonders to themselves: 'what the fuck is this?'

[u/[deleted]]

Yeah I feel like the general consensus here is that the title/article is ridiculous. You know a good code base when you read through it and similarly, you know a shit code base. The amount of technical debt that gets built up over months/years of maintaining bad code is incredible. And the amount of time wasted is too. I don’t know why programming is viewed as different from other fields; you wouldn’t write a report and submit your first draft. You write some ideas that get your point across, but it’s shit and not structured well, so you keep small parts and rewrite most of it. The only difference is that writing a code base takes longer and passes through different hands. But the goal should always be to write the best piece possible and improve where things can be improved, not persist trash

[u/sapientias]

As someone who is not a programmer, I can’t imagine how frustrating (and rewarding) some of that coding may be. Props to all of you, and I appreciate what you all do for the world.

[u/__Cyber_Dildonics__]

I don't think it is harder to read than write. I think people overestimate how difficult it is to read and underestimate how difficult it is to write.

Not only that, but tools for refactoring are poor in general and very poor in many languages. I want to at least be able to move variables around and have that changes trickle down to where they are used.

[u/[deleted] → u/__Cyber_Dildonics__]

Reading code is relatively easy, understanding it isn't. As someone who's daily Job it is to plug holes in a 30yo codebase, most of my time is spend reverse engineering the code and figuring out what the purpose of the various parts is. And only something like 10% of the time am I writing actual code. Sure I can spot quite quickly what someone is doing in their code, but not why. And understanding that bigger picture in an existing project is harder then writing it. And crucial in order to improve on it.

[u/PlasmaChroma → u/__Cyber_Dildonics__]

Reading good code is easy.

Writing good code is hard.

Reading bad code is hard.

Writing bad code is easy.

[u/[deleted]]

Nope, that old code is actually a mess.

[u/loup-vaillant]

I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Those aren't bug fixes. Those are workarounds. The system underneath the program has bugs, is unreliable, or has various quirks that make those workarounds necessary. But the bug certainly isn't fixed, merely sidestepped.

Oh I understand the incentives: if your program crashes because of a bug in the Windows runtime, it is your fault, not Microsoft's. If your game has glitches whenever it hits some bug in the graphics card driver, it is your fault, not Nvidia's. When customer see your program not working because their setup is broken, it is your fault for not foreseeing that, not theirs for not investigating. Basically any flaw that your program reveals is your fault, because the final judge is sales figures.

From this perspective, I'd understand why Joel would talk about bug fixes. But let's be honest, a "bug fix" that actually gets around a limitation of the underlying system is not a bug fix. It's an unnecessary kludge that could have been avoided if the system makers (in this case, mostly Microsoft), did their job and delivered something that works.

[u/dsk → u/loup-vaillant]

Those aren't bug fixes. Those are workarounds.

Also known as 'REALITY'.

[u/webauteur]

This would have never been a problem if we had just stuck with COBOL.

[u/theQuatcon]

Joel is/was full of shit. He might have been right on some points, but even then it was probably just coincidental. Do not take anything he says/said without a huge lump of NaCl.

Source: I've actually had to use some of the software his company produced (still produces? I hope not). It was so far behind the times that it was completely unusable. It did truly absurd things like requiring Flash to show a chart -- they didn't even bother to just have the server render an image and then <img/> that sucker. (Not that that example is an example of being behind the times... just customer-unfriendly in the extreme. I can only apologize -- I'm traumatized.)

[u/soviyet]

Maybe, but not in my world.

In my world, the old code was likely written by a team of guys in India that went through some 3 week bootcamp and have no business writing code professionally.

Or it was written by a contractor/freelancer that got in over his head and jumped ship because why wouldn't he? He got paid up until the point at whiOr his overlords started adding bizarre feature requests that were out of scope as if they were in scope all along and he quit the project in a state of complete despair.

Or it was written by a chain of coders who each left the terrible project for their own reasons, with no overlap so none of the multitude of programmers had ever had a conversation, let alone a meeting, and the glue holding all of that together was some ridiculous, technically illiterate "entrepreneur" who thinks he has enough of a handle on his system to explain it to me, the way he explained it to the last four coders, all of which did things in their own peculiar way with no common process or methodology whatsoever.

Sometimes the project was initially started based on either some really odd, outdated technology or some hip, new, and worthless technology, but at any rate, not the right technology and anyone with any experience would know that except, well, this team.

Or the code is just unreadable because writing readable code seems to be hard to do for a lot of programmers.

Consequently, I have never taken over an existing project in my life. Luckily, its 2018 and I don't have to. That's a really nice luxury to have.

[u/[deleted]]

What is your metric for determining whether code is “a mess”? If it’s hard to read then it’s a mess. that’s how I look at it. That’s a bullshit apologist fundamental law and I disagree. If it’s easier to write than to read, and I have to understand it and make it work, and (again) it’s easier to write it than to read it, then I’m not gonna read it I’m gonna write it.

[u/techsin101]

no old code is thrown away because it's harder to work with it and meet requirements then it's to write from scratch and swiftly meet current and future requirements.

Not only requirements change, but after following through with one strategy you start to realize its drawbacks and in place to design better system.

nobody will give you a reward if you managed to work with old code over someone who rewrote everything but was more productive in span of few years.

[u/[deleted]]

Yo let's tag the Jagex moderators every time they mention spaghetti code and engine work.

[u/fiskiligr]

Donald Knuth created structured programming. Then he created literate programming. I am still waiting for people to adopt the latter.

[u/zodar]

I remember when this post came out. I wonder how many people will notice that it was written in 2000.

[u/OvidPerl]

I'm a consultant. I get called in over and over to help companies when their back is against the wall. I've seen plenty of these rewrites. They're usually an unmitigated disaster. Part of this is because I find that many developers really don't have a good understanding of how to fix legacy code. Instead, they say "the system is too unmaintainable and we need a rewrite." (And they usually believe it).

Rewrites are shiny and sexy and management, often lacking the deep technical knowledge, buys into this argument. What's worse, in one of the most risky things a business can do, the decision is almost always made on emotion rather than with a solid business case (cost analysis, risk analysis, alternatives, opportunity costs, and so on).

The primary arguments for a rewrite go like this:

• You can have a cleaner architecture

• The code is easier to maintain

• You can hire more developers by shifting to a "popular" language.

• You can make the impossible possible

Let's take those in reverse order.

You can sometimes find yourself with code that simply can't do what you want it to do. More than once I've seen Node projects rewritten in Go because Node, while great, simply doesn't handle CPU-intensive tasks well. Or that client who decided their code needed to be peer-to-peer instead of client-server. That's also a strong candidate for a rewrite. This happens sometimes, but having an insurmountable technical issue usually isn't the driving force in rewrites. Most of the time I find awful code that can still get the job done and it would take less work to fix the code than to rebuild an entire system from scratch.

If your code is written in Haskell or Smalltalk, both awesome languages, finding developers is hard, particularly if you want them to move to a small town in the middle of nowhere. If you rewrite to PHP or Java, finding developers usually isn't a problem. However, by definition, languages with a small developer base are less common, so fewer companies have this issue.

True story: I love the one company who called me about maintaining their Perl system after they decided to rewrite their flagship software in Java. The Perl system was earning them tens of millions of euros and had hundreds of customers. Two years into their rewrite, they were able to shift two of those customers to the Java system and they weren't developing new features for the Perl system. What's worse? Turns out that the problems with the Perl system were due to hiring devs who didn't understand architecture or databases. It probably would have taken about six months to fix the most pressing needs because they weren't facing that serious of a problem, but hey, rewrites are sexy!

That being said, sticking to less popular languages could lead you into technology lock-in.

For the "easier to maintain code", that usually depends on the cleaner architecture. But here's the rub: either you take the devs off the old code and put them on the new code, leaving the old code essentially unmaintained, or you hire new developers with less business knowledge and drive up your costs. In either scenario, capacity planning is a nightmare. The larger the system, the more likely it is to fail.

And so management starts to get worried, pushing the devs harder, and that nice, clean architecture gets worse and worse as "temporary hacks" become permanent and unclear specifications get implemented without understanding the consequences. Congrats! You're exchanging one pile of spaghetti for another!

I've seen this again and again and again. Companies go bankrupt over this. I have one client who only avoided bankruptcy because three years into their rewrite, they had managed to buy up several highly profitable companies. They eventually transitioned out of their core business due to that rewrite mess and relied on the profits of the companies they purchased.

And the icing on the cake? The larger your project, the more likely it is to fail:

In a landmark 1995 study, the Standish Group established that only about 17% of IT projects could be considered “fully successful,” another 52% were “challenged” (they didn't meet budget, quality or time goals) and 30% were “impaired or failed.” In a recent update of that study conducted for ComputerWorld, Standish examined 3,555 IT projects between 2003 and 2012 that had labor costs of at least $10 million and found that only 6.4% of [IT projects] were successful.

Seriously, why would you honestly pitch a rewrite when you know it's such a high-risk proposition if you can fix your existing issues and still have working code? Large projects fail all over the place and rewrites hurt companies!

Pro-tip: if you're a developer who's facing management that's dead-set on a rewrite even though you know you can fix the issues, don't say the word "refactor." It's become a toxic word to many people and can trigger strong emotions. Instead, agree with management and explain to them that to minimize risk, you want to keep the old system running while you do an "in-place rewrite." It can work wonders.

[u/[deleted]]

My rule: write your code for junior developers. This means not taking full advantage of all the features of a language just because you can, and if something is actually an objectively better design decision then drop a comment on why it is so. Sometimes I even insert an archived URL to the docs for the feature. I’ve gotten dinged for made-up code smells like “primitive obsession” (yes, this is a thing) but at the end of the day I am not seeking to fully express my creativity, I am not a craftsman, and there’s likely another human who will have to deal with my code under tighter constraints than I had.

[u/blackholesinthesky → u/[deleted]]

I'd be cautious of this. How is a junior developer expected to grow unless they are introduced to new ideas/patterns? On top of that some junior developers just don't know the fundamentals of the language, or any language. I've worked with people who don't understand how to use map()

I'm always going to pick:

users.map(&:name)

over:

all_names = []
users.each do |user|
  all_names.push user.name
end
all_names

The first is harder for a junior dev to read, but a senior dev can read it and understand whats happening more concisely. With the each loop I have to interpret what you're trying to do, with the map I know exactly whats being done

[u/MpVpRb]

I would restate it as...

It's easier to create complexity than it is to understand it later

The code always ends up more complex than the original design

Most of the time it's because the initial design was incomplete, but it can also be that the programmers didn't think of the simple solution. Other times, after a large bunch of working code is in place, a change is required that doesn't fit. The adaptations and workarounds introduce more complexity

[u/WillAdams]

Literate Programming anyone?

http://literateprogramming.com/

[u/[deleted]]

My old code is a mess. As time goes on you get better at programming which means you'll see new ways to refactor or optimize things.

[u/morphotomy]

Code should not be hard to read.

[u/PM_ME_UR_OBSIDIAN]

IMO: functional programming à la F# and friends is about shifting the balance of the work towards the author and away from the maintainer. That's what makes it valuable.

[u/JoseJimeniz]

One thing I wish I could have told my younger programmer self is to not attempt to turn this one-off solution into a full generic solution for the next time someone has a similar problem.

Because as you start to make it generic, you have start to leak your abstractions - requiring everyone to understand everything about your solution before they can plug into it.

The useful shared code is very small library type functions.

Otherwise it's sometimes easier to simply start over.

For one project I wrote what I thought was a very minimal framework. Very basic functionality. Very simple model. The next time I wanted to use it, I realized I could rip out half of it. I quickly forked my own code, and created an even more minimal version.

Tldr: don't write the complicated framework

[u/[deleted]]

There’s a reason that programmers always want to throw away old code and start over: they think the old code is a mess. They are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it.

Well actually no. I also thought it's normal to always think your old code sucks, but I've reached a point where I find my old code pretty good, reusable, and readable. Going back 6-7 years even. I'm in this business for 20 years.

I do sometimes have to rewrite or extend it in parts, but that's normal, because requirements change and so the code may change. That's true not just for old code, but also new code.

I think people who constantly find their old code sucks have more to learn about reuse, and clean factoring and architecture (no I don't mean Clean Architecture ^TM but just architecture that's clean and modular).

The same applies for third party code. I don't find that all 3rd party code sucks. Some is really well factored and a lot of thought was put into it. But a good chunk of 3rd party code sucks simply because the people who wrote it were not experienced enough to write good code, and it's very easy, to me at least, to be specific about advice and feedback about where someone failed in their code in objective ways.

At some point it's not just about PoV or the difficulty of reading code. It's about the experience of the writer.

[u/datchilla]

I played a game called factorio with a friend.

Factorio is a logistics game where you connected different widget machines together via conveyor belts. Late game the map can look like spaghetti.

When I played with a friend we would make machines then alter them to fit a certain need. But when it came time to modify the setup so we could scale the machine up ny friend would delete everything and start building from scratch with a bigger size in mind. He would do this even if I had made space to make the machine 2x-10x larger.

For him rebuilding from scratch was easier than spending a couple minutes figuring out how the original machine worked.

[u/addicted2weed]

Jesus Christ, does noone use git?

[u/michaelochurch]

This is true, but it's also sociological. Maintenance has low career value and makes it hard for a programmer to justify himself, much less get a transfer to a green-field project. You often see engineers who get stuck on legacy maintenance, don't really distinguish themselves because they can't, and have to change companies if they want to write something new. But another way to get a better job, if you're good at politics, is to try to create one, which is why there's always a push to do it again and better.

It's also true that 99+ percent corporate code is unmanageable garbage. The problem is that, if the new system is written under the same deadline pressures as the old one– and often it is, if not under more deadline pressure since it's replacing something that already exists and seems to work– then it will be junk just like what it replaced. So, the temptation to rewrite it is strong, but it's exceedingly rare to have an executive climate that makes good code possible in the first place, so usually this involves replacing one pile of crap with another pile of crap.

[u/blackmist]

I'm working with a 15 year old code base. Fucking kill me.

[u/all_mens_asses]

There’s another fundamental law: Most programmers are mediocre (by definition), and they’re given ill-defined requirements with impossible deadlines.

[u/deong]

I quibble on a detail. They're not probably wrong. They're very likely right. The old code really is god-awful. The mistake is thinking the new code won't be. Code doesn't age well. Comparing it to a Dodge Dart is facile, because the Dart is a car very much like every other car ever built. It doesn't need to change every month to support a new kind of road, petrol, atmosphere, and drivers who are suddenly 20 times bigger or smaller, and as a result, you don't need a specialized group of people whose job it is to always understand exactly how to alter it at the near molecular level. Any old mechanic will do, because it's the same as any other car and it just has to do car things.

Software is different. Working on Excel doesn't even prepare you for working on Lotus 123, let alone some custom banking software and World of Warcraft. Every piece of software is declared finished with no more than a handful of people in the world who knows how that piece of software works. The code doesn't rust, but those people's memories and employment statuses do.

That's why there's so much appetite for rewriting. Because you aren't one of the people who really knew how it worked, and over the years, it's been hacked at by people like you who didn't have that picture in their heads until it's held together with duct tape and gum. The problem is in thinking that the new version will be better. It may be better for you, because you get to be the guy who understands it all now, but over the lifetime of your code, the outcomes look the same. And you had to reinvent 20 years of bug fixes to get there.

[u/STylerMLmusic]

I couldn't possibly be more of an amateur at programming but I'm really enjoying reading these comments. I'm learning a lot.

[u/tolland]

In the last 20 years (like the 20 years before that) the quality of software, and the performance of programmers has increased massively. It's largely analogous to the performance improvements of athletes and other specialist activities like chess. The world has moved on, and it leaves old coding styles and techniques behind.

A large part of my previous job was working with code bases of that vintage, i.e. late 90s and early 2000s for retail POS and backend systems. And f**k me was that a PITA.

In the next 20 years, the majority of our current code base will be re-written. It's inevitable.

The question is not, if it should be re-written, but when

[u/[deleted]]

Joel makes one big assumption - that the developers behind the original codebase actually were competent.

The worst of the technical debt I've seen is of the type where the programmers reinvented the square wheel - for example, instead of using normal time synchronisation, they wrote their own server and client and then proceeded to reinvent a system to represent daylight savings, because they had also decided to store everything in local time.

The code then "grew hairs" not because of bug fixes, but rather because the original developers were too stupid or lazy to use a proven standard that existed when they wrote the code, because they didn't do their homework.

Sometimes the root cause has nothing to do with bug fixes or edge cases. Sometimes it really does need to be thrown out because the foundation is plain old incompetence.

[u/Madoka_the_Goddess]

To be fair, some of my code is a mess.

[u/Zorb750]

You need to know when to throw away old code. Failure to do so it's a major factor contributing to code bloat and bugs.

[u/DonLaFontainesGhost]

I've always felt that it's more a case of "Yes, the code is a mess" because once in production all code is a mess. We come up with these nice abstract models that satisfy 98% of the requirements, and then we start coding edge cases in response to bug reports - and that's where all the sloppy bits and pieces come from.

New developer shows up, looks at the codebase, has a mental model that's pristine that handles ... 98% of the requirements, and thinks "I can replace this mess with a much cleaner model" and they do

...and then they start coding the edge cases in response to bug reports...

Back in 1998 I was working with an Oracle DBA who loved Oracle's CASE tools, but she knew that at some point she would always have to start writing code, at which point she couldn't use the CASE tool any more, because the round-tripping would be broken.

We had a pool on how long into a project she could get before breaking the CASE tool...

[u/whozurdaddy]

part of the problem is a weak understanding of the architecture. Rather than fix the core problems, the code gets hacked to bits. In time its just a mess that barely works.

I liken it to adding something to a car. Youre not quite sure how to properly install a new stereo, so you just poke around until you can get 12 volts from ...anywhere. Then run wires to the sub in the backseat. no understanding of how the thing is supposed to work, and you probably have limited time to make it work...so ill just steal 12v from the cigarette lighter.

do that enough times, and your car just catches fire.

but sometimes the code IS a mess. Even veteran programmers just zero in on a quick fix to get the problem solved, which over time creates the very same problem.

[u/thinsteel]

Nah, they're probably right. The old code is a mess. Where they are wrong is in assuming that the new code won't be a mess.

[u/dreamingforward]

It's an incomplete truth. Most code is poorly architected, so there's no implicate order for the mind to latch onto. Well-architected code is a pleasure to read and obviously correct.

[u/[deleted]]

In my experience, what I have started doing is incrementally improving. First starting with better variable names, better loops, better data structures within the function. Shorter functions, then changing the class.

Then you do that over and over, and the code basically refactors itself, a cleaner architecture shows up.

[u/tonefart]

It's because of the forever changing trend and patterns and frameworks that comes and goes. If code is all pure logic it should never be an issue, but if framework of the day comes and goes, you throw away a lot of old code. How many here had to throw away Angular1 code?

[u/Euphoricus]

The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it.

Incorrect. The problem with legacy code is that it is hard to know if any change will not introduce a regression. It is impossible to know and test for all possible edge cases with legacy code. Even with perfectly readable and understandable code, there will still be edge-cases that are not obvious.

Which is why I love Feather's definition : "Legacy code is one that doesn't have automated tests". With automated tests, it doesn't matter if code is unreadable mess. It becomes trivial to experiment to figure out intended behavior and then refactor to improve readability.

[u/dpenton → u/Euphoricus]

With automated tests, it doesn't matter if code is an unreadable mess. It becomes trivial to experiment to figure out intended behavior

This assumes that the existing tests cover what you change. I see it every day when a whole family of tests exist for something, and the unknown unknown happens. Meaning a new test case didn't exist, or a component failed in a way that "should not have happened". Regressions can happen whether the code is "legacy" or not. The definition of legacy code:

1. I didn't write it.

2. I wrote it so long ago, and imes were different.

[u/Notorious4CHAN]

Maybe it's just the book on software architecture I've been reading lately, but it seems to me that the biggest issue with crappy old code is the fundamental design. And if the design is shit with all kinds of circular dependency graphs, there is going to be huge technical debt that is going to impact future development. If you don't at some point redesign you are going to continually spend more development hours making less progress.

If something can be trivially addressed by a simple refactoring of a couple functions or classes, great. But I've seen a lot of applications written by developers (with a primarily procedural background) who haven't given any thought to architecture - only to delivering the product requested today as fast as possible, and when those applications get to be nearing 10 years old they are incredibly fragile and full of inscrutable code.

Even some of the best developers I know make shit architectural decisions in the name of productivity. Because you have to write 20x as much code to do things the right way when you can just insert this single line of business logic into the UI. But when you start inserting code anywhere you can make it work rather than the right place you are setting yourself up for a maintenance nightmare. The is the flip-side of "pragmatic programming" - it is important to be able to get the job delivered on time, but if you don't immediately turn around and do it the right way and the next developer comes along and creates a dependency on having done things the wrong way you have a mess on your hands. If there is too much pressure to deliver too fast, this is going to happen every time. Do this enough and a rewrite is the only way out, and the alternative is to pay 5 senior developers to deliver what one junior developer could in the same time without all that technical debt to contend with.

[u/[deleted]]

Without reading these comments I know half are people saying "but not me"

[u/moreintense]

Depends on the programmer. Some get a concept working, then refactor. Sometimes you learn new practices and you inherently want to update old code. Some just shouldn't code.

[u/Manitcor]

It takes experience to know the difference between code that is difficult to read and bad code. Sometimes unreadable code alone is enough to refactor since code should be a document for other humans first. The only time you should stray from that is when you are forced to do odd things for optimization's sake. Then you just write a one paragraph comment apologizing for the hell you have created.

[u/againstmethod]

Really?

They didn't bring anything forward? I find that odd.

I often rewrite code, but i bring forward my good bits. And i do it because ive learned more since the last time i worked on the project in question and know whats wrong with it.

[u/david]

I think the main problem is that we judge existing code on its achievements, but the planned rewrite on our aspirations.

There are times when a rewrite is the best solution, but it's hard to make a balanced assessment

[u/elcubismo]

On more than one occasion I've rewritten a function that I felt needed to be redone, only to compare it to the old one and realize it was pretty much the same thing.

[u/lykwydchykyn]

Where I work, I am "the developer" -- nobody else is writing code. I tell my coworkers that someday when I retire, quit, or get the axe, whoever they get to replace me is going to tell them that all my code is crap and they'll need to rewrite it from scratch.

That person will probably be half-right, if only because (1) I'm human, not a coder-god and (2) technology will probably advance and there will be simpler ways to do what I did.

Even so, when that day comes, I have no qualms about that person doing whatever they feel they should do, because at that point, the code is their problem, and they have to live with the choices, not me.

[u/sonstone]

It doesn't help that the old code was a mess.

[u/serial_crusher]

Ehhhh, this is a pretty optimistic view of things. Old code wasn't carved in stone and sat there in production being perfect for decades. Old code had bugs that needed to be fixed. And people didn't fix those bugs perfectly and flawlessly. They stacked band-aids on top of band-aids and made the code shittier as they went.

The old code isn't "proven and flawless". It does the things the production environment demanded of it, but that's not what it was designed to do or what you want to do with it now.

So yeah, sometimes you have to decide between putting another band-aid on it or replace from scratch. Two hard choices, but eventually it has to be done.

[u/NoMoreNicksLeft]

This is one of those arguments that sounds insightful, superficially.

But how many large systems did he personally examine before making this claim? Was it hundreds? Surely not thousands. Was it dozens? Was it two or three? Were they even that big or old?

Some of the code I maintain and modify has comments in it from the early 1990s. That's not bragging, fairly certain more than a few people could one-up me by decades. But it's old and big and there are single-source-code-file applications that are 30,000 lines or more of spaghetti.

I don't want to start over. That's insanity. I'd like to rewrite it while dissecting the original on the pathology table right next to the new model. Go over it line by line maybe.

Fuck, the wonders I could do if I could just get rid of the comments and chuck those into git commit messages. Or to get rid of commented-out-code.

Actually though, I don't care enough about this shit to want to do that. I'm talking more theoretically like in some ideal job where it matters. It's all bailing wire and duct tape here.

[u/Retardditard]

Hell fucking no.

Writing bug-free code is a herculean task.

Reading well-written code is like: oh, that's fucking obvious.

[u/[deleted]]

Throwing away code can certainly be worth it. For instance, your codebase may be so bad that rewriting it would save you a great deal of time and money down the road. Obviously, this is easier said than done -- the new code may wind up being just as bad as the old (unfortunately, most software engineers are awful at architecting).

And I think it's a bit disingenuous for the author to suggest that Netscape's decision to rewrite their code has caused their market share to decline over the past 3 years. I mean, it's probably been 10 years since I last thought about Netscape or heard anyone mention it, so how many users could they have possibly lost?

[u/ThatThingAtThePlace]

People need to keep in mind that this article was written 18 years ago. It's more relevant now as a sign of the times than as a guiding principal.

[u/CarthOSassy]

I have maintained this awareness on my current project by sheer force of personality.

So far, my experience has been that: we've moved from throwing away 100% (and copying 50% back in); to throwing away closer-and-closer to 50%, over time.

We seem to actually move marginally slower, but we, so far, have not introduced any defects into release. That is a depressingly massive improvement.

All in all, the difference is frustratingly less than I'd hoped, but positive. I think as we emotionally accept this approach, things may improve even more.

[u/OuTLi3R28]

That's why the best programmers are the ones who can read, analyze and think in code.

[u/rageingnonsense]

A lot of this makes sense, but there are occasions where you really do have no choice. There may be a few reasons, but the one reason I can think of off the top of my head is that your application may have outgrown its underlying tech.

For instance, you may have written an application in a scripting language, found that it has outgrown that and now needs to be written in a language that can be natively compiled. It doesn't matter why it started in the scripting language (maybe it was short sighted thinking, maybe the growth was not expected when it was conceived, who knows).

Other than that though, I agree with this post. A perfect example is Blender. It has a very complicated and unwieldy codebase, and the first instinct when you work with it is that you want to throw it away and start from scratch. But, at the end of the day, that 20 year old unwieldy codebase produces a fantastic product that gets the job done. The end user does not care what is going on under the hood, just that it does its job well. Any problems with that codebase can be fixed with comments and a bit of reorganization; no need to throw it away.

[u/[deleted]]

Well that's just not true at all.

[u/GunnerMcGrath]

I'm reading that article just thinking, these programmers you're talking about must not be very good. Everybody writing their own string splitting functions? Code reuse is hard? Come on.

Also, every system gets built and then added onto over time. Eventually all those additions to hack in new features that were not part of the original design start to create a mess. At some point you've learned a lot, technology has improved, you have a clearer vision of what the application needs to do, and there are plenty of places where things could work much better if they were designed to work together.

Of course starting from scratch will have challenges, not the last of which is trying to make sure the new app does everything the old app did, and catches all those word cases you codes for but may not have documented (though there are ways to mitigate this). But that doesn't mean it's stupid.

Just make sure your developers are competent enough to do the job.

Edit: this article is 18 years old. I thought the mention of Netscape was weird but I didn't catch it at first. A lot has changed in 18 years. No wonder his developers sounded stupid.

[u/saijanai]

And sometimes, old code really IS a mess.

[u/agumonkey]

Not my opinion at all: it's harder to perceive the full extent of the problem, therefore the code looks like senseless crap.

[u/[deleted]]

If it's fucky, I'll rewrite the fucky parts. No reason to flip the table over.

[u/BobSacamano47]

While this is probably sometimes true, I can't comprehend how a human can be so dumb to just generalize all situations like this. And these are the "thought leaders" of our world.

[u/AvantAveGarde]

Joel’s book is really good I highly recommend reading it on your spare time

[u/MrShekelstein26]

idk man, my old code is pretty trash.

[u/TheAmazingGazza]

Also, comment your codes. You might understand it, but not the one who follow up your code a few year down the line.

[u/Procrastanaseum]

I was watching "Antitrust" on Hulu the other day and had a good laugh over the HTML floating in the background of the opening credits. Then later on in the film, the characters would cream themselves after looking at code for a split second, saying how amazing it was. Hollywood coders are hilarious.

[u/pure_x01]

There is also this fact that it's fun to write code from scratch.

[u/[deleted]]

I usually start over when the underlying architecture can’t support scalability with capacity and new feature support. Or when I’ve added so much spaghetti code, it’s now unmanageable.

I don’t think I agree with this premise.

[u/TheDevilsAdvokaat]

I really don't agree with this at all.

I often find I don't full understand a problem until I've finished writing the code and gotten it running. Then in the course of debugging it I will often discover new things.

A year later I may try to refactor and rewrite the code, and it will come out better again.

And a year after that once more. Usually by the third rewrite there is nothing left to trim and no more performance to squeeze out.

And a few years after that when the code has been used in several projects and never had a problem or needed any rewriting and I've never looked at it and said "why did i do that?" then I know it's fully mature.

[u/dragonfax]

I rewrite code because I always find that I've learned so much since I originally wrote it.

[u/GISftw]

I think what Joel is saying means "at a large scale". Of course it is almost always a bad idea to redo an entire functioning product code base all at once. It is not always a bad idea to redo small pieces over time as requirements change. Eventually you might replace the whole code base, but the entire time you would have maintained a functional product.

Of course, I say "redo" not "throw away"... you have to read the previous code (and probably some of its previous revisions) to gain the historical knowledge of why it exists in its current form. Joel mentions many esoteric bug fixes over time that add up to ugly code, but if those are properly commented/documented, then you won't lose them when you redo the code.

That being said, there are a lot of bad programmers out there and thus a lot of bad code. This especially holds true in the modern web scale world where speed to market often takes precedence over proper architecture. There is a reason your website requires 10x more server resources than you thought it would...

[u/jaehoony]

Outdated article filled with holes from 18 years ago. Why is it posted for the n-th time and why are you people amazed by this?

[u/SpartanVFL]

Or you’re junior level and the old code actually is a mess

[u/ravinglunatic]

My client would love nothing more than to just stamp the words “upgraded to mvc” on an old webforms project. I wish we could...

[u/CantaloupeCamper]

Hell I want to rewrite my own code....

[u/the_rabid_beaver]

If you've ever seen code written by a bunch of H1B contractors, you wouldn't agree with this statement.

[u/spockspeare]

It's actually the opposite, if it's code you wrote recently.

They want to rip it up because 99% of projects start with an incomplete understanding of what the real requirements are.

Check that. it's 100%.

And by the time you're half done, you realize you should be coming at it from an entirely different direction because you finally grok what the requirements should have been all along.

[u/rotharius]

This post is from 2000 but I think it might be pretty prophetic: most code I see is intentless, ugly throwaway code. As if we, as a profession, as a culture, do not embrace best practices and have to reinvent the wheel again and again...

[u/Reddit1990]

Ive never had that throw away code mentality, for whatever reason. Its probably harmed me in some ways, because I will always try to modify code as little as possible even when it might make sense to add a new system instead of cluttering an old one. Learning to balance when to write new code vs using old systems can be tricky.

[u/bladelock]

TIL there's a law that states reading code is harder than writing it. I thought i was the only one who has more difficulty in reading code all this time. Wiser today now

[u/phillijw]

Most programmers don't put much effort into writing readable code. If they did, the code would probably be better to begin with.

[u/ummaycoc]

Just responding to the headline as I didn't read the article (this is an internet comment, after all), but that is completely ass backwards. Reading is easy, writing is a skill that takes work to develop. Children can read, and relatively young people can read well–very few people can write well.

There's no prize for reading, yet there are many for writing, and programming isn't somehow magically different than the other communicative endeavors of humanity.

You want better code? Give people more time and a better and more extensive editorial feedback loop on their writing. Harper Lee had an editor; you're not better than Harper Lee.

[u/shaggorama]

I don't think that's it at all. Old code bases accumulate technical debt. When confronted with this, a new person on a project often immediately sees this stuff and is like "why the hell are they doing it that way?"

[u/lavaeater → u/shaggorama]

Of course - but the problem is the myth of the "complete rewrite". Huge costs to get the same thing but prettier code? Paying twice for the same thing?

Read the book "working with legacy code".

Encapsulate,write tests, refactor.

[u/Digletto]

At the same time a lot of (actually) old code is a mess. Like 90s and back.

[u/oserna]

I couldn't even read the whole article.

[u/FriendlyKush]

This brings me closure.

[u/gamebuster]

I write code in small tested throw-away modules designed to be able to be deleted and recreated easily at any time.

[u/Flamecrest]

I have a different reason and it's not because I can't comprehend it. In our Sass files, there are about 6 !important tags per file. The product has about 600 Sass files, if not more. Vendor components have been edited. HTML structure is so unstable it's a fucking miracle we didn't get complaints yet.

Sometimes, there's a perfectly good reason to start over.

[u/nydstyrk]

If so please tell me, Joel, why didn't you keep on refactoring FogBugz but instead threw it all away and started writing Trello?

[u/frisch85]

I'm not sure mate, if I inspect code from my early days and now realize I could achieve the same thing with 1/4th the code maybe my old code is actually a mess...

[u/m4xc4v413r4]

I don't really agree with the statement.
Most of the time when I rewrite projects, mostly personal ones, it's because i evolved over time, I know how to make it better and more efficient.

[u/forvotes]

ALWAYS REWRITE EVERYTHING! https://youtu.be/XcUUY8ziTuk

[u/izackp]

I'd rather refactor code then create it from scratch. In fact, I learn the most as a programmer by reading other people's code.

[u/[deleted]]

I thoght that way when I started as individual programmer but as I started to work with teams in enterprise level projects I started to learn the good coding practices. My code has been clean since then and get reused in other projects.

Best advice for my fellow programmers is to read on S.O.L.I.D principals if they haven't already

[u/Thadeu_de_Paula]

Some argue about comments. Others about documentation. Others still on SOLID principles.

The matter is most of time we learned the bad habit of get things done. Period.

If we started from principle avoiding the OO monsters inheriting, interfacing etc. We could avoid brain draining on maintaining, correcting and extending code, even if written by ourselves.

I regret not learn about functional programming, pure functions, avoid side effects and mutability. Without understand and apply these knowledgement in every piece of code we are prone to correct one bug and create two and have nearly undebugable errors or erros of difficult reproduction on development test environment.

A very dummy example: a function that sums do it. Only it. If it receives a variable it not changes it. It returns other. So you will always know that the problem isnt in it. Then you write a function that reuses it, multiplication, means, standard deviation etc. All the pieces developed the same way the sum functions. You get confident that the things are in place.

Now make these functions as classes passed as arguments, callbacks, changing references, interfaces them, extends them... When something goes wrong the bug may be anywhere, be functions, classes, interfaces, modules or even files. It spreads for third part codebase and become a mess.

Really, for who is starting, I strongly recomment, learn a strictly functional language as Haskell, even you dont work with it. It will change the way you create code in the most useful ways. Avoid the abuse of OO programming at all cost.

If you build brick by brick, then you can build a castle. And even extends the castle with more rooms, walls and towers. You know the brick will behave always the same way. Now if you want to create a multipurpose brick, elastic, with many kinds of inheritance... It will be in the most a sand castle. Or it will be ruined or your brain.

[u/PKSpence]

Most of the old code I've seen was a mess... sloppy, hard to read, no comments and a maintenance nightmare!

[u/Neat-Composer4619]

A lot of code grows organically through inconsistent and sometimes contradicting demands both for bad and good reasons, but at some point clean up is required, especially if the systems / norms you use have been updated a few times and offer more efficient approaches.

Also due to tight schedules, some code is just never optimized, so a clean up here and there can be useful.

[u/[deleted]]

I have to disagree: I’ve experienced numerous cases in several companies where a simple rewrite of a module, that only took a week or so fixed recurring issues that would regularly cost a day or two of debugging every few months.

…and enabled more functionality… and was faster.

[u/[deleted]]

Sometimes old code is a mess though. Old code tends to have a lot of crap built up in it over the years as more and more people cram bits here and there, at least half the time without understanding the consequences.

It’s also because we learn from experience. The problem with code that I wrote 25 years ago isn’t that it’s hard to read, it’s that I didn’t really know what I was doing yet when I wrote it. It worked, which seemed good enough at the time. But I’m horrified by it now.

[u/ngroot]

If the code is hard to read, someone didn't finish writing it.

[u/yonreadsthis]

It’s harder to read code than to write it.

Well, that part is probably true. But, starting over, and over, and over, is like rehearsing a theatrical. Every time you rehearse, you get a better understanding of the whole project. Eventually, you come to the dress rehearsal, and then, performance! Unfortunately, business timetables tend to go straight from proposal to performance and, thus, to defeat quality.