4 ms·
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 - d
by 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 agoAll 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.