Thursday, June 07, 2007

Often I have heard people try to describe software. If it can be described then maybe we can formalize it and then make the process of software development more like a true engineering process.

I propose that one should think of software like the blue prints of a house instead of thinking of software like components, objects, and building parts. Let me try to explain. I do not think that when a software developer is writing code he is building the metaphoric walls, floors, and roof of the house.

Before I go any further I want to stop and say I am not saying modules, objects, and other abstraction and organization techniques should not be used.

Software is a set of instructions that will be executed by a computer. These instructions are created in a manner that is suitable for humans to create, organize, and maintain but they are still just instructions. These instructions are turned over the the computer for processing. So if we go back to the house building analogy then the software engineer creates a set of instructions or blueprints on how to build the house and the computer's processor actually builds the house. Each time the software is launched the proverbial house is being rebuilt.

To further the analogy it would be like delivering a blueprint of the house along with ordered sequential instructions to guide every step and every action of the house builders. It might go like this: "Worker pick up hammer. Worker drive nail." But wait, we didn't tell the worker to pick up a nail and we didn't even have the worker standing in front of the wall in which we wish to drive the nail.

The interesting thing about using the house building analogy it is almost like the house is built when it is needed to be used and then it is torn down and all of its resources are available to be used by someone else. So it is like all of the nails that we used to build the house are available to use to build something else when our house is not in use. Nails are a resource needed to build a house. Similarly a storage device such as a hard drive is needed to store the software. Resources are finite that is to say there are only so many nails available or so much disk space available.

Once a house is built it continues to consume resources such as water and electricity. Software after it is built consumes memory and use resources like the network or video card. If there is no electricity the "house" fails to provide such things as light or heat to the customer. If there is no more memory the software fails to perform desired functions.

Thinking of software in this way helps one understand why software fails even though it had performed fine for months. Software depends upon the resources available in the environment for which it exists. The availability of resources change and thus software that worked before now fails. How the software fails is described as a level of robustness. Robust software fails nicely. That is the programmer provided instructions to the computer to do something in case there isn't enough memory or the network connection is down. To go back to the house building analogy it would be like giving instructions to the builder "Get a 6 penny nail. If there are no 6 penny nails then get an 8 penny nail. If there are no 8 penny nails then signal your boss you will wait until there are some nails..."

Software is just a set of instructions to be performed by a computer processing unit. Software is not some carved out thing on a hard drive that leaps to the forefront when you click on it.