Re^6: Strange behavior: Class::DBI with CGI::Application

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 ]

Comment on Re^6: Strange behavior: Class::DBI with CGI::Application

Replies are listed 'Best First'.
Re^7: Strange behavior: Class::DBI with CGI::Application by dragonchild (Archbishop) on Feb 23, 2005 at 17:58 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^7: Strange behavior: Class::DBI with CGI::Application
by dragonchild (Archbishop) on Feb 23, 2005 at 17:58 UTC

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.

[reply]