Backwards Compatibility | July 1, 2015 |
---|---|
One of the questions we are faced with often as developers is the question of backwards compatibility. When is it appropriate to tear down your previous work and switch to something completely new that should work better than what you had before? For some time now, I have followed the mobile carriers with great interest, especially T-Mobile. This is in part because I am a T-Mobile customer, but it is also because it is fascinating how T-Mobile has changed and re-invented itself. As a result of all the work they have put in so far, T-Mobile has been growing for many quarters now, and has finally left behind the dark days where they were literally bleeding money. Now, they are competing with the other big three carriers (Verizon, AT&T, and Sprint) and forcing those carriers to compete as well, which benefits all of us as consumers. In that time, the growth in subscribers that T-Mobile has sustained has been remarkable. At the time that AT&T tried to buy T-Mobile in 2011, T-Mobile had 33.6 million customers. Last quarter (ending in March 2015), T-Mobile reported having 56.8 million customers. This kind of growth, however, doesn't come without its issues. All carriers have given great importance to the speeds at which it provides mobile data, as we increasingly use more mobile data. The problem for for wireless carriers is that their networks can get congested more easily that wired ISP's, since they run their networks over limited amounts of the airwaves (or spectrum as it is commonly referred to). As more users connect to a network, the more that spectrum has to be split between them, resulting in a more poor experience for all those users. Carriers have responded to the explosion in mobile data use by going crazy buying more spectrum or in carriers cannabilizing their 2G and 3G networks and moving that spectrum to more efficient 4G networks. T-Mobile is also not standing still and is currently shutting down parts of its 3G AWS network to make more room for 4G LTE. T-Mobile originally deployed its 3G network over AWS spectrum, which operates at 1700 MHz and 2100 MHz. By contrast, AT&T and most other GSM carriers in North America used PCS spectrum operating at 1900 MHz for their 3G deployments. Since T-Mobile operated its 3G network on a somewhat unusual set of frequencies, most of its early phones came with support for only AWS 3G, some of which are still in use today. Now, T-Mobile began to deploy PCS 3G, since that allows users to switch more easily to T-Mobile, especially from AT&T since all of their 3G phones have support PCS 3G. Now you can probably see the dilemma that T-Mobile is in. On the one hand, people complain about slow speeds in certain areas, especially areas where T-Mobile has less spectrum to deploy (like the cities of Chicago and Cincinnati). This would be helped (if not resolved) through the AWS 3G shutdown. On the other hand, however, shutting down AWS 3G will cause some customers with phones that don't support PCS 3G or 4G LTE to lose data service. T-Mobile has decided that it is more worth to move its spectrum to 4G LTE and start shutting down AWS 3G. There are certain to be customers that are not going to be happy, since they will have to either get a new phone or lose data service. T-Mobile is spending time and effort contacting customers still on older, AWS 3G only phones and offering a free upgrade so they don't lose any service. This is an excellent example of how a backwards compatibility issue is dealt with. T-Mobile reached a point where the benefits of refarming their spectrum to 4G LTE was worth more than the effort needed to ensure their customers still using AWS 3G phones were upgraded to more modern phones that don't require accessing AWS 3G. In the end, even if they do lose a few customers, they will end up improving the experience for the rest of the users, making them more likely to stay and to recommend T-Mobile service to others. When faced with complex issues like this one, we are usually given the suggestion to weigh the pros and cons of each of our choices and to choose the one with the most pros and least cons. Issues regarding backward compatibility are no different, and for the most part, this is how such issues are and should be handled. In fact, it seems that most of the time, things reach a threshold, when you are actually doing a lot more work trying to patch and fix something to maintain backwards compatibility than it would be to just start with something completely new. We must therefore be aware of reaching that threshold and be ready to throw away our previous work, as hard as that may be, to be sure we are always providing our very best. |
Welcome! | July 1, 2015 |
---|---|
First of all, welcome to my personal website! I thank you for visiting my website and for taking the time to read this blog. I will be keeping a blog on this page where I will talk about anything that interests me. For the most part, this blog will be technology related, since that is what I am most interested, but don't be surprised if I also touch on other subjects as I have interests in many different fields. Feel free to read more about me in my "About" page. If you have any suggestions or comments for me, also feel free to go to my "Contact" page so you can send me an e-mail or a tweet. |