Kent Beck is not talking about rewriting from scratch. He's explaining how to transform software to a better state by taking tiny steps in changing the existing system.
I suppose you could interpret Joel's essay as a bit of an agreement with Kent's take. That even though you might have to pass through a trough of despair to rework some old code into something better - that's still a better path to follow than a ground-up rewrite.
I'd usually agree, especially as things get big.
But Kent is also pretty famous for throwing out code if things aren't shaping up. He does this in micro increments however, usually with just-written code.
I've just spent years wrestling with someone else's poorly written, ill-intentioned code, bringing it into line. I've taken the above approach of slowly reworking it. Sometimes I wonder if I just kept the tests and jettisoned large bits of it if I'd be better off?
Very contextual of course, but sometimes you have to explore a little bit to know the right places to make tradeoffs.
> I've just spent years wrestling with someone else's poorly written, ill-intentioned code, bringing it into line. I've taken the above approach of slowly reworking it. Sometimes I wonder if I just kept the tests and jettisoned large bits of it if I'd be better off?
That's the main reason we have this discussion in the first place IMO. There is no one right answer to the question.
Which is why I find folks that throw out Joel's article to be a little black and white. Like "never rewrite anything from scratch".
It takes many years to develop good intuition around this stuff though, so I appreciate that as a first approximation. It can get a little dogmatic amongst senior folks though.
When it comes to a whole application rewrite, I'm pretty certain you should at least be much closer to "never ever rewrite" than "in some cases rewriting makes sense"
If you are talking about refactoring or changing/replacing parts of a system - that's not the same thing. At least to me
>I've just spent years wrestling with someone else's poorly written, ill-intentioned code, bringing it into line. I've taken the above approach of slowly reworking it. Sometimes I wonder if I just kept the tests and jettisoned large bits of it if I'd be better off?
I find it really depends on the level of nuance required of the final behavior. Maybe the test suite doesn't cover certain implicit requirements of the software, often a bug becomes a feature without anybody noticing in sufficiently old projects.
Likewise the tests might not even be structured in a way that's conducive to a rewrite, depending on their level of specificity. Maybe you only care about the final, black box behavior and individual unit tests should be thrown out so you don't need to adhere to existing function I/O requirements.
I've made a career out of bashing half-baked code into shape, or dragging legacy code to meet new needs. You have tests? You can be much more confident about where you're going. Usually the first thing I do when dealing with code is write some tests to capture how it behaves now, before making any changes.
That sounds familiar :) Keep in mind the existing tests are typically half-baked too, so there's lots of additional testing going on no matter what.
Sometimes I just reflect on YEARS mucking with code written from someone that was just learning, and I wonder if I'm a little too in the "sunk cost investment" mindset. Hard to tell I suppose, but certainly worth thinking about.
It seems no one here quite knows what he is talking about.
Then you read his latest book "Tidy First" and it tells you when you move out multiplying width and height into an area function you have now made a beneficial design change in your system and the relationship between caller and box, a "tiny step". And suddenly all the doubts wash away.
Not sure what it is with this industry, but the writing is just useless.
