3 ms·

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

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.

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.