Grady Booch is passionate about his work, which has seen him encounter some bizarre physical barriers on software as well as documenting and archiving programs from the past, writes Karlin Lillington

Not many people could begin a sentence with "After booting the house...", but IBM fellow and software design guru Mr Grady Booch is not your typical home owner.

He and his wife have just built a home in Colorado, which features five miles of high-speed fibreoptic cable, a Web server, 19 network nodes and a terabyte server.

He recently discovered a tricky little problem with his wired home when his dinner guests had to phone him to get him to open the front door "What had happened was, my doorbell had crashed," he says, with the kind of pleasure only select alpha geeks get from such an unlikely scenario.

His doorbell was one of his network nodes - instead of the wiring simply running from the doorbell to a ringer, the doorbell was wired into his broadcast network so that speakers throughout the house would announce that someone was at the front door.Something had gone wrong and, as a result, the guests rang and rang the bell and nothing happened.

"I had to boot the doorbell," he says with further relish.

His audience at Dublin City University, who have come to hear this seminal figure in the software field speak about the limits of software, are delighted with the tale. But it's not just a spare anecdote - it is the start of his argument that software architects need to build simplicity into their products.

Or more precisely, he says, "the illusion of simplicity". The wires and nodes and networks and servers are all back there, somewhere. The user should just see the doorbell and the doorbell, of course, should work.

"Inasmuch as the bones stick through, we've failed as software designers," he says.

But the task is not easy when, as he notes, "the entire history of software engineering is characterised by rising levels of abstraction". The abstraction, he believes, should be hidden away, but that task grows increasingly difficult.

Greater complexity and abstraction across a range of areas are beginning to place limits on the development of software, he says. These he maps onto a conical diagram that graduates between two extremes - the fundamental limits hard science place on software development and the limits imposed by human factors.

So at one end of his cone sit "The Laws of Physics" while at the other end are "The Limits of Human Imagination". These and the points in between make for a fascinating exploration of aspects of software development that often aren't articulated or conceptualised.

Setting aside the fact that Mr Booch believes some software shouldn't be developed even if it can - either because the costs are too high in comparison to the task at hand, or for moral or ethical reasons - many other spanners of various sizes can be thrown into the development works.

His work at NASA's Pasadena Jet Propulsion Lab have led him to encounter some of the more bizarre physical barriers on software - something most people think of as entirely virtual, without weight or other physical properties.

But when software is sent into space, it goes in the form of programs etched onto computer memory. Thus a program suddenly must be thought of in terms of its weight.

Software developers will also soon bump up against the physical limits of Moore's Law - that processors will double in power and capability and decrease in size and price every 18 months. Processors can go down to the atomic level but, beyond a certain point, things grow so small that quantum physics takes over. Developers would be required to write quantum programs - whatever those might be.

Certain 'laws of software' - the limits of what a program can do - also constrain development, as do problems with finding new and better algorithms (the mathematical formulas underlying software programming), issues around security and distributed systems, and software design problems.

As the cone moves further towards the "human" end, Mr Booch enumerates problems of economics (is there value to be gained by writing a particular program even if it can be done?), the influence of politics, either internationally, nationally or simply within an organisation, and the limits of human imagination.

Interestingly, he argues that the technical problems are not the biggest issues in development.

"We need the computer science breakthroughs, but the primary things that are barriers are not technical, but on the funny fringe of the technical and social."

Many "points of friction" that create barriers to software development are centred on the people side - working collaboratively, poor communication, lack of time to get work done, lack of stakeholder co-operation and what he calls "stuff that doesn't work."

On the physical side, he says, "Moore's Law has allowed us to be sloppy".

As computing power has grown and the cost of it has shrunk, "we have been seduced by this glut of computing power and have built systems that are more and more inefficient".

After his talk, he notes that he thinks the issues around software development often are invisible to the public. "Software has moved into the interstitial spaces of the world," becoming more ubiquitous in cars, planes, shops, and our general work and play environments.

"There's a tremendous amount of it being built. But there are still lots of problems to overcome, to build it efficiently."

That makes him confident that the software industry will grow and thrive, despite the recent downturn within the sector.

One of his current projects is to write a handbook of software architecture. A problem with understanding software design is that it is not linear in the way that physical engineering is - design a bridge and the structural issues can be examined and calculations tested to make sure the bridge is physically sound. "But software systems are discontinuous in nature. They defy the normal kind of analysis."

The handbook will examine types of software architecture to document and expose it.

A favourite project is helping to document and archive early software programs - a task he is doing at the Computer History Museum in Silicon Valley. Not only is this an important project to preserve the design of early programs and help understand how software has changed over time and how some pioneering programmers thought, it is also an effort to combat the rising tide of software patents, he says.

Within those old programs is much "prior art" - proof that a given idea has already been conceived, tested and used. The discovery of prior art should halt many spurious attempts to patent software programs and processes, he believes.

But at the heart of his enthusiasm is a pure love of the medium: "I believe there's an intrinsic beauty of software."

Grady Booch's weblog: www.booch.com/architecture/blog.jsp