I came accross this article, which goes into one of the major software design misconceptions out there. I've heard this echoed many times: XML doesn't have to be compact, the network will get faster; Java doesn't have to be fast computers will get faster, etc.
I've also seen many systems bogged down with fundamental designs enforcing poor performance. Most of the time the problem is designers that don't understand the impact of shared resources on a web server. They worry about CPU cycles on individual requests when they use a property heavy remote object, or abuse a database with multiple small requests in a transaction.
Especially with ado.net making it so easy to get data from the database developers don't realize that making a request to the database is akin to driving to the store to get a couple of eggs while you are in the middle of a recipie. If you are going to go that far to get something, you should make sure you get everything you need all on that one trip. The more you can cram into those few packets the better.
To carry the analogy further. It doesn't take that long to run to the store in most cases, but when the road gets congested everyone has to wait. The same thing happens when the network or database server gets overloaded. Every database request on every page gets slowed down and each additional wait time gets added to the page. Eventually it reaches a critical point where the delays just multiply one on top of the other and everything just shuts down.
Anyway, I thought this was a really interesting read.