After you have profiled why the machine is dying on 1000 hits/hour, you'll find that there are 2-3 specific places that the code is choking on. That means you only optimize 2-3 specific places. This is contrast to optimizing the whole damn application because you don't know where the slowdowns are going to be.

That results in a much lower overall cost to the owner of the application. What you haven't described is the differences between Frobnitz.com and Squonk.com. For example, what about

• The costs to get it written
• The speed at which it was written
• How many developers needed to maintain the code, both for bugfixes and enhancements
• How many bugs there are in the application, especially how many are user-facing
• The time it takes for a new developer to come up to speed
• What the damn thing is doing (does it depend on outside resources like a RDBMS?)

It may be that Frobnitz got up and running in 2 weeks with 2 developers as opposed to Squonk in 16 weeks with 5 developers (4 man-weeks vs. 80 man-weeks). Additionally, Frobintz only requires 2-3 hours/month in maintenance vs. Squonk who needs a full-time maintainer. That's because Frobnitz's bug-queue has never gotten beyond 2 bugs (total) and Squonk has 4 high-priority bugs in it at all times, two of which impact a large segment of the userbase. The complexity of the codebase means that it takes 2-3 months to get up to speed on Squonk, but we can have a random contractor come in for 2 weeks at a time and deal with the Frobnitz issues. Oh, yeah, and Frobnitz depends on a bunch of webservices (which aren't under our control) while Squonk is completely self-contained.

Admittedly, this is a somewhat contrived example, but you see where I'm going with this ...

I see what you mean, and I think you see what I mean. However, business customers rarely look at the six bullets you mention, they look at the cost of lost opportunities incurred because you didn't whack off the top three or four obvious optimizations in the first place. They also react rather emotionally when something costs them money.

The first failure of a commercial system should be due to operating conditions WAY WAY outside the contracted scope.

There's a parable that says that the Romans had such good bridges because when completed, the Caesar forced the architect to stand underneath them while the army traveled across them. If only software engineers should believe their lives depended on meeting and exceeding the contracted operational scope.

--
[ e d @ h a l l e y . c c ]

Halley, I know we said we expected Frobnitz.com to get a thousand hits a week, . . . The machine keeps falling over, and we're only getting a thousand hits an hour.

The first failure of a commercial system should be due to operating conditions WAY WAY outside the contracted scope.

Explain to me how a request rate 168 times the contracted hit rate is not WAY WAY outside scope. I really want to hear this explanation. I would argue that this is seriously outside the contracted scope. In fact, the client is now asking for a completely different system. I would write a system very different if I expected 1 hit every ~6 minutes vs. 1 hit every ~3 seconds.

In the first, I'm optimizing completely for speed of delivery + minimizing of bugs. The system should be up and running ASAP because the client can't afford to pay me much if he's only expecting 1000 hits/week.

In the second, I'm optimizing a lot harder for performance, which means I'm going to take longer to write the application because I'm paying more attention to infrastructure and resource utilization. This is ok because the client expects a higher income and can afford to invest more while still achieving a sufficient ROI.

They also react rather emotionally when something costs them money.

If I was in the Frobnitz/Squonk situation you brought up, I would calmly look at the client and say "You're complaining that you're bringing in 168 times the traffic ... why?" At that point, they will start to look sheepish and mutter a little under their breath because they just realized that their $2000 investment that they expected to recoup in a month is now being recouped every hour and that they can afford to spend an additional $5000-$10000 to bring it up to snuff.

. . . they look at the cost of lost opportunities incurred because you didn't whack off the top three or four obvious optimizations in the first place.

Let's say I did the three or four obvious optimizations in the first place. This means that instead of one week and a total developer cost of $2000, it now costs at least 2 weeks (at $2000/week). Instead of recouping their costs in a month, they now have to go several months before recouping their investment. What's the business case again for coding to 1000 hits/hour?

Our job as developers is not to code for what we would like - it's to code for what we are paid to do. And, that is a very, very hard lesson to learn. You don't get to write a new system every time. You don't get to rip stuff out and start from scratch. You have to maintain, extend, and not break anything while you're doing it. Don't give your client a Porsche when a bicycle would do.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.