Software developers used to work within relatively extreme constraints. Memory was sharply limited and processors were slow. As processors have continued to double capacity about every two years, those constraints have become relatively unimportant. But that also means developers no longer have to consider code efficiency as they once did. Read more here.

For most, perhaps nearly all developers these days, the "efficiency" of their apps (how much memory is consumed)  is often the last thing they think about when creating a new application. Their top priority is making sure the app performs well, not whether it will consume an inordinate amount of data. App Developers and the Data Cap Dilemma

"It's actually generally the last – it's pretty low on the priority list," says Patrick Emmons, co-founder of Web and application development firm Adage Technologies.Emmons says this isn't because developers are lazy or unconcerned about their apps hogging an ordinate amount of data. As he explains it, data efficiency goes hand in hand with the performance of an app, so there's no need to specifically prioritize data use.Build a well-performing app, and chances are it will use data more efficiently than an app that performs badly. "It's kind of a corollary issue," Emmons says.

One might argue there is a somewhat-similar corollary in the broader application provider business. Third-party apps do not pay directly for use of broadband access connections, so there generally is no business imperative to design apps in ways that minimize bandwidth consumption or signaling overhead. That is less true in the mobile domain, though, as signaling issues with the iPhone have in the past been redesigned to affect the mobile signaling network less intensively. Signaling can cause network congestion

In the mobile domain, the design of an application can affect the amount of network traffic. Read more here. Still, app providers haven't had to worry much about the bandwidth implications too much, except to watch as access speeds have improved, in principle improving user experience for most applications. 

That could get to be an issue, in some cases, as more apps incorporate video and other media types that require sustained access to both high-quality and fair amounts of bandwidth. Of course, the other issue is an industry-wide switch to buckets of usage, rather than formally "unlimited" plans. Where in the past a streaming video provider might not have had to worry about bucket of bandwidth issues, that likely will become more important. That is one reason Netflix allows users to select from three "quality" settings when watching streaming video, emphasizing either image quality or bandwidth economy. User defined bandwidth settings can be important.

In principle, subscriber or partner payments for bandwidth almost have to grow substantially over time. The reason is the simple change in revenue dynamics for all communication service providers. Basically, where 70 percent of revenue is generated by voice, service providers must assume that contribution will continue to decline over time, forcing providers to generate an equivalent amount of replacement revenue from broadband services to compensate. If one assumes that voice services ultimately will be a smallish revenue contributor, then broadband services must grow to replace nearly all current voice revenue. 

As an example, if one assumes that a triple play service costing $130 a month consists of three services each generating about $43 a month, and voice will drop from $43 a month to perhaps $10 a month, then the other services must increase in price by a combined $33 a month, just to keep revenues neutral. If one allocates half of the increase to video and other services, and half to broadband access, then today's $43 a month access service becomes a $60 a month service, for example. 

The peril of abundance is that developers do not have to code for efficiency. The network equivalent is that as applications start incorporating more video, more bandwidth is required. And, as Netflix already has done, in some cases "efficiency" might start to become a more important design requirement.