When Worse Is Better (Kent Beck)

I experienced reading this as a major slap in the face. When faced with a local maximum, my immediate gut reaction is "hooray, major redesign! whiteboards, here we come!". It's the part I like the most.

Yet, I know he's right. I'm going to have a hard time holding back and accepting incremental change here, too.

Get the Wall Street Journal to do an article about you, which is how I assume Kent did it.

Then don't.

His is just another piece of advice in an industry where, like all others, no piece of advice is universally applicable.

For example, when it comes to major refactoring of a large chunk of code that has been in maintenance mode for a while, you can benefit from hindsight: hopefully you've seen the code at work, you know the strengths and weaknesses of the design, and you have an opportunity to build a new design with more strengths and fewer weaknesses, because now you have a better understanding of the problem you're trying to solve.

I don't think that what he's suggesting is all that radical, either. Is it really so rare to move some system from one environment to another in piecemeal fashion? I'm certain I've done it at least a few times. Is it now a radical suggestion to break some arbitrary coding standards in order to improve some functionality or untangle some mess? I should hope not.

nope. seems like a bunch of nice ideas but the results are not even close in style and "artistic quality" to Kent's photo or the original example from mathematica.stockechange... seems like the only way to have it done by an artist... or maybe combine by hand contours and "fills" generated by the different techniques in that thread... anyway, thanks a lot for the link, whenever I'll be in the mood of wanting to sharpen my artistic sword I'll take a shot at this...

I'm not sure the part you like most is counter to Beck's incremental degradation process. Presumably you'd want to have a general idea of where you're going before you start tearing things down.

Take his single-server, multi-server example: The problem you are presented with is that you have too little capacity (I'll assume). The multi-server architecture is one way to solve that. The decision to start tearing down the monolithic server so that you can distribute the workload may not be "Big Design Up-Front", but there is at least a little design up-front.

Think of the "driving a car a night" metaphor for agile: You may not be able to see beyond your headlights (and hence may not know the exact route you'll take along the way), but you need to know if you're driving to New York or California.