Technolog

The first rule of holes is that when you are in one, you need to stop digging. But up until recently, the standard position of the software industry, upon finding itself disappearing below ground level, has been to hire a JCB and dig much, much faster in the hope that it will somehow outrun the problem and pop out near Sydney Harbour bridge in time for the fireworks. And so the issue of difficult-to-use software has been addressed by the successive addition of buttons, menus and features. It is become more prone to failure and more difficult to use, not less.

It is the depth of this hole that has been the problem. The vast open-cast mine of the PC software world, with all its associated machinery, support structures and financial dependents, is so well established the people involved in it cannot countenance the idea that it is all one huge mistake. From the outside, it was beginning to look like the situation was hopeless.

Now let’s take a pseudo-random selection of the current hottest computing acronyms and buzzwords: XML, CSS, SOAP, object orientation, Java and UPnP. Each of these is a form of technological concrete designed to cover the mess. How and why should this happen now? To a large extent, it is down to hardware. These new software technologies and platforms need modern hardware to be viable – lots of speed, storage capacity and bandwidth.

For it is not only laziness and a lack of organisation that has led us up this garden path. A lack of processing power, memory and bandwidth has been a prime mover. Complex, incompatible binary file formats; hideous programmer-unfriendly code; and ridiculous situations like the millennium bug all came about because computing resources were scarce.

But look! The Java programming language has rapidly become the mainstay of the corporate middleware world. In enterprise back offices, getting the job done effectively and reliably matters more than anything. Java has thrived in this relatively prejudice-free environment: it can glue disparate systems together like nothing else because it is platform independent and a wonderfully clear language to develop, meaning fewer bugs and more easily manageable applications. But Java has two flaws: it is slow compared to most other languages and it is memory hungry.

That’s a trade-off you see everywhere: ease of use, simplicity and transparency require, first, abandonment of the entrenched ways of doing things and, second, plenty of computing power. XML requires the disk space for large data structures in plain text (not compressed binary formats); UPnP needs the bandwidth to work with several layers of protocols (including HTTP and XML), which are inefficient in the technical sense; SOAP (the simple object access protocol, note the ‘simple’) is a subset of XML designed to assist with moving object-orientated data structures around; CSS needs fast processors to parse and render heavily layered, human-readable layout information; and object orientation – which makes for modular, clean code – means lots of discrete, elegant but memory-intensive data structures in preference to super-efficient spaghetti code. Java is an object-orientated language, which is one of the secrets of its success.

If you are wondering how this solves the problem of software festooned with irrelevant garbage features, I will tell you. The emergence of structured, human-readable (but not necessarily ultra-efficient) simplicity is changing the mindset of the whole industry. Computing resources are becoming plentiful enough that developers can relax a little, gain some confidence and start recoding from the ground up. The computing world was once entirely implementation centric; now it can afford to be solution centric. This is, of course, the way it should always have been. Even Microsoft is doing it, as evinced by its ongoing adoption of XML as the primary data format for Office files.