An actual engineer would know bandwidth isn't something measured in bits per second.

Technically, bandwidth is the width of a band of frequencies. For example, the bandwidth between 3 GHz and 4 GHz is 1 GHz. The bandwidth of an 802.11 channel is 22 MHz.

Obviously it's a lost cause trying to stop everyone from using "bandwidth" to mean throughput or a data rate. Don't get me started on people using bandwidth to mean how much work they can handle either: "I don't have the bandwidth to handle another project, you better give it to somebody else."

</useless but informative gripe>

The problem is that sort of interjection ruins the conversation and interrupts the communication of ideas that are bigger than the individual words that comprise them.

It's revenge!

But seriously, we also do it a lot to ourselves. There seems to be a programmer mindset -- experiencing our ability to figure things out using deduction and documentation, we get conditioned to think we can quickly get a working handle on anything. As a result, engineers and scientists of all sorts are constantly annoyed at computer guys posting stupid things. (But at least we can unite in our exasperation at journalists.)

We programmers live, "There's nothing more dangerous than a little knowledge." Often we live with the consequences. (In the late 90's I despaired at the dilution of the language around Object Orientation. Things have gotten better since then, somehow.)

For persons who are designing web applications, the post outlines considerations that are not generally known or well understood. Some considerations, such as managing the number of round trips also apply to app<->database connections.