Disagree completely. Firstly, I'm not saying we should forsake Knuth's advice - I don't think his advice ever really covered architectural decisions. It's mor

Disagree completely. Firstly, I'm not saying we should forsake Knuth's advice - I don't think his advice ever really covered architectural decisions. It's more that I've seen it applied (incorrectly, imo) to justify some obviously questionable decisions. Changing my API to add bulk retrieval is easy. Changing all (or a significant fraction of) the code that depends on that API to take advantage of the change is hard, particularly when you're working on an enormous product. Unfortunately this is an example of a situation where you often experience death by a thousand cuts, and IME the 97%/3% split doesn't hold up at all. I think the other reason I think it's worth caring about this stuff up front is because it's not terrifyingly hard/time consuming, and applying simple considerations such that you don't screw yourself later doesn't have to impose an excessive tax upon your codebase quality. The same is often not true of pervasive code microoptimisation. I suppose there's an extent to which such basic architectural decisions could be likened to simply 'doing the right thing' when you're coding - using sets instead of arrays for 'contains?' heavy code, and so on. I guess I've just seen several projects make obvious blunders when starting up that could have been averted by a pretty small amount of thinking ahead.