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.
Comments
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.