When Worse Is Better (Kent Beck)

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.

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.

http://mathematica.stackexchange.com/questions/8716/how-to-c...