> Sometimes you have to optimize for your development time first and product

> development goals, and leave the optimization till you get a bit of runway.

That's a typical way to postpone and fall into a trap. Not all optimizations take huge amounts of time. And certainly there are some architectural decisions you can take early on that can save you a lot of wasted time later. The most common is to prevent bottlenecks.

For example, it's not necessary to make a clustered DB from launch day but coding and managing the UI and middle-ware to be ready for a switch to clustered DB usually takes very little impact. If you don't do this and the site becomes successful, re-engineering your whole site to support a new DB is usually close to impossible or extremely expensive. The site ends up in the DB hardware feedback trap just like in the article.

Edit: format fix.

Architectural decisions also limit what you can do later. Generally, the more focussed/optimized a system the less flexible. To the extent you KNOW exactly what the system should do, it should be optimized from the beginning; but, as PG points out repeatedly, most startups change direction at least once after launch.

"Had the app been as efficient three years ago as it is today, I'm estimating that about half of what was spent on hardware and related licensing and support costs would not have been necessary."

So first off the software costs where far higher than the HW costs. Second, possible savings of 750k would have come at the cost of features or development time both of which have costs. If anything this just points out how expensive using Microsoft solutions can be when you need to scale. But, even still I expect over 3 years the 750k "lost" is an insignificant cost vs the cost of development and roll out.

PS: Reading between the lines the HW costs where probably well under 150k. "up to 30% of 32 database cores all by themselves."

At the time, IBM, Unisys and Bull were about the only vendors with SQL 2000 capable servers with > 8 CPU's. (And Itanium, of course.)

The customer purchased IBM x460's, 16 CPU's, 64GB RAM = $225k each in 2005, right after they came out. Three required (active, passive in a cluster at the production site and one for the DR hot site). Upgrade them to dual core x3950's six months later = another 200K (or so, the upgrade was to 16 dual cores, 128BG RAM for each of the three database servers ). Plus all the odd's and ends, like 60 amp 3 phase power, 70,000 btu's of cooling, etc.

The software/licensing/support costs were because with > 8 sockets, you needed Microsoft Data Center Edition, and at that time, it came with an expensive support contract ($70k/yr).

Had the vendor been about 6 or 12 months ahead on their optimization, the 16 CPU x460's could have been 8 dual cores instead, and the 32 core upgrade probably wouldn't have been needed - or if it was, it could have been delayed until quad cores were available, the expensive OS support would not have been needed, half as many Microsoft SQL Enterprise CPU licenses would have been needed, and the 24x7 hardware maint contracts would have been half as much, etc.

It’s stunning how much people can overpay on just about anything.

However, even if every cent of that was "needed" we are still only talking about ((3 *225 + 200) /2 ) ~= 440k in HW which is ~1/3 of the stated number and probably a small percentage of the budget over those 3 years + dev time.

PS: I know they would have saved a lot of money by using 8 CPU machines, but that's part of my point. Scaling the DB system has little to do with the app code and it shows just another way the project was miss managed.