No offense, but I think most of you are wearing rose colored glasses here.

Specifically, you have the following points backwards:

1) Failing to deliver a working product is guaranteed to fail your project, even if delivering it on time will have bottlenecks.

2) Foreseeing *ALL* the bottlenecks can really only be done by top people. Most of us will have to see it work to identify all the bottlenecks, even if we knew where some of them would be

3) Foreseeing scale of application and availability of investment ratios is something most of us will not be able to do from the trenches. These decisions often get made by management and bean counters. You will have to work with them, not complain about them.

4) Implication of #3 is that while it might be cheaper in TCO to make a tuned app from the beginning, the value/funding may not exist until gets to the point where it has the bottleneck. By then, iron may be 10x cheaper.

5) Throwing iron at a problem doesn't just make one problem faster, it usually makes most of it faster. This means you're not comparing a single problem to the cost of iron. You're comparing overall app benefit to the cost of new iron.

6) Before you buy iron, you obviously should identify what part of the iron to invest in. If your server is not CPU bound, buying faster CPUs will not help much.

It's my opinion that the best solutions are not the "slick" ones which take a crappy architecture and makes it blazing fast for one feature. It's the solutions which make it so some junior person can come in, learn one standard for how to know what goes where, learn one standard for coding (perhaps a couple of reference implementations), and the monitoring already in place will yell at them when they do their stuff wrong, before it makes it to production (examples: Integration Tests/Continuous Integration/Continuous Deployment).

In a properly delivered design, you would test at an appropriate scale to where you see the application going in the near future. I am *NOT* advocating a pre-optimization. I am advocating you deliver something tested for the requirements you have (or should have).

Most of the time, you can get one of the top answers just by implementing obvious patterns over and over. Once that stops working, you should implement a new pattern, not just a one-off.

I hate to see crappy apps as much as the next guy, but if we're talking about investment vs rewards, we should really talk about this from the business point of view, because that's how we deliver the value other people care about.

Just my two cents.