October 27, 2008 10:46 AM
Wasting Bandwidth: Caps Hurt App Development?
I came across this really interesting post on Slashdot.org last week from a user who's trying to find ways to not waste bandwidth.
He (or she) shares that their broadband connection has a cap of 1GB per month and that they're charged at a rate of 2.5 cents per MB thereafter.
What's been frustrating for them is that so many sites nowadays have a tendency to send more and more data regardless of whether or not you want it. He even cites things like how if you watch a YouTube video, click a link, but then try to go back to that original video it has to load again even though it was just downloaded a few minutes earlier.
While wherever this user is located has much lower bandwidth caps than anything being discussed here in the States, it does speak to an inevitable outcome of any cap: the need to ration your usage to avoid paying overage fees.
This makes me wonder what will happen moving forward in terms of app development as a result of this. Already developers have to spend a lot of time trying to squeeze as much data as possible through a tiny pipe. Now we're also going to make them worry about conserving bandwidth over time as well.
In some ways this may not be all bad as it may lead to more efficient apps as well as efforts to improve the user experience of that YouTube example above, plus often where you introduce limitations it affords an opportunity for creativity to thrive to overcome these boundaries.
But at the same time, I can't help but worry that this could also lead to more time being wasted trying to overcome the limitations of broadband infrastructure rather than staying focused on developing exciting new applications that rely on the availability of lots of bandwidth.
This may be especially true for the growing number of apps that demand not just high bandwidth but that that throughput be sustained for a long period of time, like when watching a high quality live webcast or utilizing terminal computing where you access a virtual computer over the network and your apps reside on a server rather than your desktop.
Also, from the user perspective, I hate that we're now going to be forcing users to start worrying about how much bandwidth they're using at a time when we've still got so much work to do to encourage them to want to use more in the first place. And without that demand for more bandwidth we won't be able to get the networks that'll supply big bandwidth connectivity.
Don't get me wrong, I'm all for finding more efficient ways to utilize networks. I figure the more we can do with less, then ultimately the more we'll be able to do with more once the capacity's there to do so. And I completely respect the need for network operators to find ways to maintain a viable business in the face of growing demand for bandwidth overwhelming the standard all-you-can-eat model of broadband service.
But even still, I can't help but find myself frustrated that at a time when I and others are trying to find ways to get people to use more bandwidth to prove the need for full fiber networks we're simultaneously entering an era when apps developers and users may need to worry about using less.