Una pequeña historia que saque de un libro

Por William Ryan

A few years ago, I worked at a company where the software manager had
utter disdain for most programmatic details. He hated database
normalization. He hated object-oriented design. Basically, he hated any
answer other than, "Yes sir, that deadline won't be a problem." We did
minimal testing as well (he hated testing too), but typically our
applications performed well in our test cases. After our applications
were deployed to customer sites, however, we'd start having problems
with both bugs and performance. The software manager's immediate answer
to any performance problem was to buy more RAM.

In one instance, we upgraded our application from 2 GB of RAM to 12 GB.
This solution wasn't cheap. Unfortunately, the version of Microsoft SQL
Server we were using supported only 2 GB of RAM—those extra 10 GBs were
a total waste as far as our application was concerned. So our manager
insisted that we upgrade the SQL Server version. Once the new SQL Server
was running and using all 12 GB, there
was a slight performance gain but it was still unacceptable to the
client. Next our manager blamed the client's hardware: "We've got a
Ferrari running on bicycle tires with this configuration." So he
recommended the client get more hardware. At this point, the client
already had spent over $20,000 more than
they had planned, so they weren't budging on hardware. Our company, of
course, had to absorb this additional cost. After the client had the new
hardware in place, performance improved slightly but not enough to make
a difference. Now the system was $40,000 over budget.

Next our manager blamed the network configuration: we couldn't use
100-MB pipes any more; we needed 1-GB pipes. After spending another
$4,000, we had 1 GB of network bandwidth, but once again there was not
enough benefit to fix the poor performance. Left with nothing else to
point a finger at, our manager
finally blamed Microsoft. Windows 2000 Server and SQL Server 2000 were
the problem. After all, things ran a lot faster on old green-screen
applications, and with all that new hardware, how could it not be
Microsoft's fault?

The real problems all along were as follows:
* Bad data structures on the database (one of our tables had 255 columns
and many others were close to this large)
* Excessive use of cursors, and cursors that were poorly written
* Single-threaded execution for everything

Had our manager bothered to diagnose the problem beforehand, a lot of
time and money would have been saved. Had he bothered to diagnose the
problem before finger-pointing, he might not have presided over a
successful company's quick demise. The moral of the story: Before you
start spending money or time fixing problems, make sure you thoroughly
understand what the problems are.