Published: 01/02/2009 | Last Revision: 06/07/2010

The push towards the laptop as a core business platform has caused all sorts of issues to come to a head again. Although of course, in the world of IT, there really is nothing new under the sun – the same old problems rear their ugly heads time and time again, and just get wrapped up with a new naming convention. With the laptop, we have had an interesting journey. Back in the 1980s and 90s, a laptop was a luxury. For the same money, you could have a much higher performance desktop. The screens were poor, the processing power limited, the storage small, and hooking it up to thin Ethernet was a pain. Worse still, the battery life could often be measured in minutes. But that wasn’t the end of the problems. These devices really only worked when hooked up to a local LAN. So they were, at best, transportable devices.

Are our portable applications as cumbersome as our portable computers used to be?

Today, it’s all change. Somewhere in the last ten years, the available horsepower on the desktop exceeded the needs of the majority of users. I’m not sure precisely when this happened with the laptop platform, but Intel’s Core 2 Duo must take some responsibility for it. Today, the laptop is almost unrecognisable compared to that of a decade ago. Dual core is the standard. High resolution screens are the norm, and disk storage runs to hundreds of gigabytes. Even more importantly, we now have wi-fi in a wide scale deployment, and 3G data cards are not the Star Trek wishful thinking of a decade ago. Battery life has improved out of all recognition, especially when taking the processor power into account. So is there really any great surprise that the laptop is taking over as the premiere business platform? In some ways, no it is not a surprise. All the power of a desktop in something you can take on a plane. Unfortunately, this has allowed some bad thinking to get into production. For example, how many people encrypt the hard disk on their laptop? Not enough, it seems from the various reports of massive data leakage. And therein lies a big problem. Today’s top-end laptop has the power of a supercomputer and the storage capacity of Marvin The Paranoid Android. When that middle level executive wanders out of the front door with his work laptop in his briefcase, it can be quite staggering just how much information is going with him on his laptop. In truth, we have been having something of a busman’s holiday with the Web. The big push to HTML presentation has meant that real data has been forced to stay within the confines of the data centre, with only the HTML (or XML and style sheet, if you are being really whizzy) coming over the wire. This has helped a great deal with our roaming users on their laptops. The data requirement for an HTML can easily be much less than a badly written page of data from an HR or ordering system. The end result is that we have forgotten our roots. Back in the old days, when client/server SQL applications were written with the client running on the desktop, it was a matter of imperative that no-one ever did a ‘Select * from Table’ as the result would be that the network, meandering along at a sturdy 10mbit/sec would melt under the data load. You would think that only pushing the HTML webpage to the client would make it lightweight, but today’s expectations mean that pages often have large dynamic elements in them, with whole sections of Web pages including detail that can be collapsed away out of sight. And those long combo lists of textual content all need to be populated too. Worse still, we used to be happy with just the core information, but today we want pictures - or even worse video streams - as well.

So there is no great surprise that some applications which have an ostensibly lightweight HTML front end can end up sucking badly when run across an EDGE GPRS laptop connection from a car parked in the middle of a business park. Because we can run data to laptops, we are now expected to do so as a matter of course, and yet little real testing happens on many projects. This really matters, because we have to balance the amount of data held locally on the machine against the data streamed over the network. Even when using ‘eat all you can’ data plans, the connectivity required to keep a laptop fed can be significant. And things get worse when we start talking about Software as a Service. Not because SAAS has intrinsically higher network connectivity requirements, but because we are talking about a plumbing which most of us are not used to using. Because of this, it is absolutely paramount that proper testing for data connectivity requirements are part of the modern testing of an application. It is not good enough to say “it’s HTML, it’s OK it will work just fine.” If we are to take best advantage of SAAS, and the possibilities for Cloud Computing whereby some of our application is held at our business premises, and other parts are sitting in a data centre somewhere outside the country, then testing needs to become much more sophisticated. The design needs to be much more savvy too. What happens if you cannot connect to the data centre, for example? Is the application simply going to sit there sucking its thumb, waiting for the electrons to flow? No, of course not: a distributed over-the-wire solution requires failure modes that actively takes into account the likelihood of various parts of the infrastructure being available – or not. Are we developing applications with such flexibility in mind? Or are we just quietly whistling a happy tune, in the hope that no-one really notices? I think that some difficult questions need to be asked of the infrastructure of applications designed for laptops connected via dodgy bits of wet string like 3G and GPRS connections. And in the bigger picture, if we deconstruct our large scale applications into services which run on multiple servers, distributed around the globe, do we have the means to monitor and control these things in real time? Will this be an incentive to keep services big and monolithic? Time will tell.