I have been thinking a bit lately about the process of writing computer programs. It is a process with many phases, often overlapping and always intertwined.

I had thought that writing software was different from any other occupation, but now I am not so sure – I don’t have lot of experience of too many other occupations. Sure, I have done other things, but not for a long time, and there a many thousands of other occupations that I know nothing about. So maybe it isn’t all that different. I don’t know.

But what I do know is this – when you create software you have an almost out-of-body experience. You are certainly in another world.

The first step is getting the requirements. For the freelance developer like me that is, in itself, an unusual experience, and I have to say a very enjoyable one. I don’t much like doing business analysis, but I do like meeting new clients and talking to old clients about new projects. There are two aspects to this.

First, you get to meet all sorts of different people. I spend most of my time locked in my office talking to no one. It is a welcome change to talk to real people. Sometimes you forget that other people exist. (If my wife reads this, please note carefully I don’t mean you.)

The other good thing is that you find out all about their business through the programs that they need written. You sometimes see small businesses around and you think, “I could do that.” But when I talk to these people and see what is involved in what they do I soon realise that there is no way that I could do that.

Then comes the writing of the business requirements. The less said about that the better. But it must be done. Well, if you plan on writing the program that the client is expecting then it must be done.

Now we get on to the fun stuff. Systems Analysis and programming. It depends upon the size of the job as to how much I separate these two. I usually do them together. Do some anaylysis, then do some coding. Analyse the next component. Do the coding. Of course, for larger or more complex jobs you need to get your analysis down pat earlier on because the components will each have an impact on each other. But for smaller jobs I can usually keep track of that through my business specs.

When you are in the process of putting the software together you seem to move into an almost transcendental plane of existence. You aren’t dealing with real-world objects. Oh, they may be modelled on real world objects but you can’t go to the cupboard and pull out, for example, an inherited class. Nor is your car likey to undergo polymorphism, unless you fell asleep at the wheel.

And the writing. It is in a strange language. Once you get on a roll you are thinking in that language. I work at home, and if my wife comes into my room when I am in the middle of something relatively complex it is very difficult to talk to her. My mind is thinking in English. It is thinking in VB.NET or PHP or, heaven forbid, Prolog.

And the downside is that once you are interrupted and brought back to the real world it takes a long time to get back into the programming language world you previously occupied. I think a 2 minute interruption probably means 20 minutes downtime.

This has taught me a serious lesson. If you are in the middle of something complex then stay until you have it solved. I don’t know how many times I have been stumped and thought “I’ll get a cup of coffee and then figure this out.” You get the coffee but by then all the thoughts in the other language have left you. You are back in real time. And it takes enormous effort to go back.

The problem with all this is that sometimes in the middle of a large project I dream in code, and in my dreams the answers are all very straightforward. But come the light of day those solutions were utter rubbish.