9 ms·

> Don't rewrite code without consultation. This is linked to a pet peeve of mine, especially with restless, young developers. There's a significant difference

by marcusf 15y ago

> Don't rewrite code without consultation. This is linked to a pet peeve of mine, especially with restless, young developers. There's a significant difference between the two statements "I don't get this code, it's crap, let's rewrite it." and "I understand this code, it's crap, let's rewrite it". I don't know how many times I've seen someone go down the path of seing battle-tested code, not understanding it, thinking they can rewrite it better only to spend a month falling in to all the same pitfalls that lead to the original code. The middle road is of course refactoring. Cleaning up the code in small, discrete steps to something you can understand and work with is many times better than just tearing stuff out and restarting.

adrianhoward 15y ago
If anybody on the team can spend a month going down a rabbit hole rewriting code then there's something seriously wrong regardless :-) The "Don't rewrite code without consultation" was the only one of Jeff's points I would niggle with. I love environments where there is collective code ownership - everybody being free to edit any code without asking first. It encourages everybody to keep the code in a state where that's possible, lowers the barriers to getting code improved, and helps lower the bus number by getting more people familiar with more of the code base. But for it to work you need an environment where you have rapid feedback, regular integration of changes, etc. If those times are measured in days, weeks or - deity forbid - months then you're heading for trouble.
- bmj 15y ago
  But for it to work you need an environment where you have rapid feedback, regular integration of changes, etc. If those times are measured in days, weeks or - deity forbid - months then you're heading for trouble. This is a big caveat for lots of developers. Not everyone works in such an "agile" environment. Another poster has already linked to Joel's essay on rewrites, and that's written with his experience at Microsoft in mind. There's also a matter of testing. If you have a group of testers slated for a release, suddenly dropping a bunch of regressions on them will seriously skew their time lines. That's not say that the environment you describe isn't a good thing--it's just not reality for many of us.
  - adrianhoward 15y ago
    All too true. I'm just fascinated by the interrelationships between technical practices. The way that a "good" practice can become "bad" (and vice versa) depending on the working context can be very hard to figure out. Testing would be another one that would come into play here (and I guess that it's interesting that it didn't even occur to me to mention it since having a good automated test suite is so much of the way that I work now). Without a good test suite having collective code ownership becomes much harder because making some dumb mistake that breaks something unintentionally becomes much harder to spot.
- marcusf 15y ago
  Sorry, 'months' was ill-chosen. FWIW, it's usually measured in hours where I'm currently at, but I've seen projects where people have spent literally weeks doing inane refactorings and rewrites, or where that has been the dictated norm ("We must rewrite our user management system, it's busted").
- gaius 15y ago
  I love environments where there is collective code ownership - everybody being free to edit any code without asking first. You can only do that in the most trivial environments (e.g. layout on a webpage) without destroying the mental state of everyone who is working on that codebase. Imagine having to waste half your day getting "up to speed" every day because nothing is as you left it. No-one should be irreplaceable, but any piece of code should have no more than two regular owners.
  - adrianhoward 15y ago
    And yet I've worked several places with some decidedly non-trivial code where we quite happily did do this. None of us were wasting half a day getting up to speed because of things like: * More of us being familiar with more of the code - so less to get confused about * Lots of small functional commits, so the changes tend to be small * We were bright enough to go have a conversation with everybody if we see changes that are going to affect lots of people * We had an excellent test suite that prevented regressions, and was a good tool for getting up to speed with changes that had been made Quite frankly - the idea of planning a business around only two people really groking bits of the code base is a bit frightening to me.
essayist 15y ago
Joel Spolsky's illuminating screed on Netscape rewriting its browser from scratch is apropos here: The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- nostrademons 15y ago
  It tends to acquire bugs because ideas of what it should do change over time, and so what used to be correct behavior is no longer. Which also gives you useful guidelines for deciding when to rewrite. Identify the design assumptions of the system. Identify which ones of them no longer hold. If you can't identify these, leave it be - there's probably something important in there that you don't understand. If you can identify them but there are ways of making the existing system meet the new requirements, refactor, don't rewrite. Only rewrite if the fundamental assumptions of the system, ones that permeate the whole system design, have changed.
romaniv 15y ago
There's a significant difference between the two statements "I don't get this code, it's crap, let's rewrite it." and "I understand this code, it's crap, let's rewrite it". There are cases when the code is a convoluted, buggy, unintelligible, undocumented, untested and untestable mess. In those cases re-analyzing what it should do and re-implementing it from scratch is often both faster and more reliable way of dealing with required changes. Especially if you consider resources spent on maintenance over a significant period of time. At this point, I get the nasty feeling that many people who preach "don't ever rewrite" mantra are the people who have produced large volumes of code in the past, but consider themselves too "senior" to maintain it now. The common rhetoric regarding "young/junior programmers" only confirms that notion.
- tedunangst 15y ago
  Analyzing what the code should do is insufficient. You must also know what it does do. Somewhere, someone is depending on that and they will be angry when your rewrite, perfectly spec conforming though it may be, doesn't work the way it used to work.
  - georgemcbay 15y ago
    And if you aren't working in a pure functional environment, you must also know what the code does not do.
  - romaniv 15y ago
    Any change to a badly written application can break some obscure functionality or integration. I repeat, any change. Assuming that you're still working on the codebase in question (and why else someone would care to rewrite it?) there is a constant threat of breaking changes. Heck, with certain types of code regular issues after updates are nearly inevitable. If you rewrite something, you will at least have understanding of how things work right now, which allows you to quickly and reliably deal with surfacing compatibility issues. On the other hand, updating legacy code to deal with those issue is a) much slower b) likely to introduce other issues. And no, you cannot always slowly refactor old code. That is, in many cases it will take several orders of magnitude more time that a complete rewrite with new features plus all the rewrite issue mitigation. Been there, seen that. Many times. So far I haven't regretted a single rewrite I've done in my professional life. If your experience is different, than maybe, just maybe, you should look at how you approach rewrites, rather than dismissing the whole concept as "wrong".
timwiseman 15y ago
I think it depends. If the original author (or most recent modifier) is available then "I don't get this code" means I should be scheduling some time to talk to them. If the original author is completely unavailable and I am the new maintainer, then "I don't get this code" might be a valid reason to rewrite it. Even if I can't improve it, by the end of it I will know what those pitfalls are and understand that code.
div 15y ago
I could not agree more. One should always have a "fools rush in" attitude when contemplating rewriting a piece of code he did not write himself. Always.

by marcusf 15y ago

adrianhoward 15y ago

If anybody on the team can spend a month going down a rabbit hole rewriting code then there's something seriously wrong regardless :-) The "Don't rewrite code without consultation" was the only one of Jeff's points I would niggle with. I love environments where there is collective code ownership - everybody being free to edit any code without asking first. It encourages everybody to keep the code in a state where that's possible, lowers the barriers to getting code improved, and helps lower the bus number by getting more people familiar with more of the code base. But for it to work you need an environment where you have rapid feedback, regular integration of changes, etc. If those times are measured in days, weeks or - deity forbid - months then you're heading for trouble.

bmj 15y ago
But for it to work you need an environment where you have rapid feedback, regular integration of changes, etc. If those times are measured in days, weeks or - deity forbid - months then you're heading for trouble. This is a big caveat for lots of developers. Not everyone works in such an "agile" environment. Another poster has already linked to Joel's essay on rewrites, and that's written with his experience at Microsoft in mind. There's also a matter of testing. If you have a group of testers slated for a release, suddenly dropping a bunch of regressions on them will seriously skew their time lines. That's not say that the environment you describe isn't a good thing--it's just not reality for many of us.
- adrianhoward 15y ago
  All too true. I'm just fascinated by the interrelationships between technical practices. The way that a "good" practice can become "bad" (and vice versa) depending on the working context can be very hard to figure out. Testing would be another one that would come into play here (and I guess that it's interesting that it didn't even occur to me to mention it since having a good automated test suite is so much of the way that I work now). Without a good test suite having collective code ownership becomes much harder because making some dumb mistake that breaks something unintentionally becomes much harder to spot.
marcusf 15y ago
Sorry, 'months' was ill-chosen. FWIW, it's usually measured in hours where I'm currently at, but I've seen projects where people have spent literally weeks doing inane refactorings and rewrites, or where that has been the dictated norm ("We must rewrite our user management system, it's busted").
gaius 15y ago
I love environments where there is collective code ownership - everybody being free to edit any code without asking first. You can only do that in the most trivial environments (e.g. layout on a webpage) without destroying the mental state of everyone who is working on that codebase. Imagine having to waste half your day getting "up to speed" every day because nothing is as you left it. No-one should be irreplaceable, but any piece of code should have no more than two regular owners.
- adrianhoward 15y ago
  And yet I've worked several places with some decidedly non-trivial code where we quite happily did do this. None of us were wasting half a day getting up to speed because of things like: * More of us being familiar with more of the code - so less to get confused about * Lots of small functional commits, so the changes tend to be small * We were bright enough to go have a conversation with everybody if we see changes that are going to affect lots of people * We had an excellent test suite that prevented regressions, and was a good tool for getting up to speed with changes that had been made Quite frankly - the idea of planning a business around only two people really groking bits of the code base is a bit frightening to me.

essayist 15y ago

Joel Spolsky's illuminating screed on Netscape rewriting its browser from scratch is apropos here: The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

nostrademons 15y ago
It tends to acquire bugs because ideas of what it should do change over time, and so what used to be correct behavior is no longer. Which also gives you useful guidelines for deciding when to rewrite. Identify the design assumptions of the system. Identify which ones of them no longer hold. If you can't identify these, leave it be - there's probably something important in there that you don't understand. If you can identify them but there are ways of making the existing system meet the new requirements, refactor, don't rewrite. Only rewrite if the fundamental assumptions of the system, ones that permeate the whole system design, have changed.

romaniv 15y ago

There's a significant difference between the two statements "I don't get this code, it's crap, let's rewrite it." and "I understand this code, it's crap, let's rewrite it". There are cases when the code is a convoluted, buggy, unintelligible, undocumented, untested and untestable mess. In those cases re-analyzing what it should do and re-implementing it from scratch is often both faster and more reliable way of dealing with required changes. Especially if you consider resources spent on maintenance over a significant period of time. At this point, I get the nasty feeling that many people who preach "don't ever rewrite" mantra are the people who have produced large volumes of code in the past, but consider themselves too "senior" to maintain it now. The common rhetoric regarding "young/junior programmers" only confirms that notion.

tedunangst 15y ago
Analyzing what the code should do is insufficient. You must also know what it does do. Somewhere, someone is depending on that and they will be angry when your rewrite, perfectly spec conforming though it may be, doesn't work the way it used to work.
- georgemcbay 15y ago
  And if you aren't working in a pure functional environment, you must also know what the code does not do.
- romaniv 15y ago
  Any change to a badly written application can break some obscure functionality or integration. I repeat, any change. Assuming that you're still working on the codebase in question (and why else someone would care to rewrite it?) there is a constant threat of breaking changes. Heck, with certain types of code regular issues after updates are nearly inevitable. If you rewrite something, you will at least have understanding of how things work right now, which allows you to quickly and reliably deal with surfacing compatibility issues. On the other hand, updating legacy code to deal with those issue is a) much slower b) likely to introduce other issues. And no, you cannot always slowly refactor old code. That is, in many cases it will take several orders of magnitude more time that a complete rewrite with new features plus all the rewrite issue mitigation. Been there, seen that. Many times. So far I haven't regretted a single rewrite I've done in my professional life. If your experience is different, than maybe, just maybe, you should look at how you approach rewrites, rather than dismissing the whole concept as "wrong".

timwiseman 15y ago

I think it depends. If the original author (or most recent modifier) is available then "I don't get this code" means I should be scheduling some time to talk to them. If the original author is completely unavailable and I am the new maintainer, then "I don't get this code" might be a valid reason to rewrite it. Even if I can't improve it, by the end of it I will know what those pitfalls are and understand that code.

div 15y ago

I could not agree more. One should always have a "fools rush in" attitude when contemplating rewriting a piece of code he did not write himself. Always.