Title: Thinking Aloud

I mentioned earlier that there were a series of bugs discovered in open source software. It was unfortunate that this happened just after two of the larger Linux distributors (Red Hat and SuSE) had launched new versions. However, I had a graphical example of the difference in proprietary software treatment of reported bugs and that of open source software.

Without exception fixes for the open source bugs were available within days, if not hours, of the bug reports being filed. Very impressive.

While this was going on we were tracking down a bug in Borland's C++ Builder™ 5 library. Now I have to say, this was not an easy process. I wrote the original code, and was sure it was a mistake on my part. I looked at the code on and off for nearly a month, but could not see what I was doing wrong. At this stage I decided that I needed someone else to look at it - I was probably reading what I meant to code, rather than what I had actually coded.

I sent the code off to another programmer to look at and he worked on it for nearly three weeks before he finally isolated the bug and was able to prove that it was a bug in the library code. OK, so there was probably some delay because I was convinced that it was my error and insisted he keep investigating my code for longer than he would have done if left alone. Even so this was a substantial use of our resources. Once I was convinced it was a library bug it took nearly a week to construct a sample program that displayed the problem. Even for that you had to run the program under the debugger to see the incorrect memory access in the destructor.

So we spent all this time finding a bug in Borland's software, more time constructing a program that would enable them to identify the bug, and then we sent a report off to them. A couple of days later we got a note accepting that it was a bug in their library. And then...

Nothing! No patch, not even a work around, and as I write this it is now nearly two months since we reported the bug.

Fortunately this is an internal tool, and the bug only affects a destructor that is called immediately before the program terminates. If it ran under Linux or another Unix variant it would not be too much of a problem because the operating system would clean up the undeallocated memory. Unfortunately Windows leaves the memory allocated, so people using the program have to reboot periodically to reclaim the lost memory.

Why was I so convinced the error was mine? Well that's a bit difficult to explain. I guess it is to do with the fact that I am very wary of blaming problems on any software other than my own. It is my experience that when a bug rears its ugly head given even a slim fraction of a chance most programmers will blame any other software that is around other than their own.

I have had to virtually prove it could not be other software so often in order to force people to do serious debugging on their programs that I suspect I am probably leaning in the opposite direction.

It is desperately important that people should be able to trust their tools. Software development is built on trust - the trust that the tools you are using to build your applications are not flawed. The problem is that once a problem is found with the tools the trust breaks down and when anything goes wrong the natural reaction is to blame something that has already been found to be at fault.

It matters not that the application programmer's work has had many more bugs than the tools have shown, it is easy and natural to blame the tools for any further faults found. Fortunately, I wrote this program and I am aware of the problem, so I can be stern with myself about such backsliding.

The fact remains, though, that if this had been a program for sale it would have been a disaster - months of delay in putting the product on the market, possibly having to completely rewrite it. Not good.

I do not know about other people, but every few weeks an e-mail appears in my mail box from one or other of our customers - usually the younger ones asking either 'How do I become a programmer' or 'How do I become a game designer'.

The first question is not as easy as it sounds, because the people asking it come from a wide variety of different countries. Most are American, some are from the UK, but I have been asked by customers from countries as far apart as Australia, Brazil, Hong Kong, Malaya, Russia and Turkey.

Eventually I got round to pulling some of the answers to 'How do I become a programmer' together on my website. If you regularly get asked, please feel free to 'borrow' material from my answers for your own use. The URL to access it is at http://www.ibgames.net/alan/society/programmer.html.

Finally, if you have not yet read my Secretary's report in this issue, I would urge you to do so, not merely because it is a scintillating example of journalistic excellence that will delight and entertain you, but because it deals with the subject of software patents. What happens to the rules governing software patents in the next few years is going to have a major effect on the way in which we work in the future. Do not miss out on the opportunity to have your say.

Have fun programming, may all your bugs be small ones.

Editorial Note

A couple of days ago, I read a news report on the subject of patents. That report stated that the decisions on changing the European Patent position would be taken before the closure date for public comment. I hope I am mistaken because this issue is far too serious to take lightly.

I am seeing increasing evidence that US patent law and its interpretation is a major disaster in the making. The problem as I see it is that a mechanism for rewarding inventors for revealing trade secrets concerned with physical devices and processes for production has been subverted to handle other kinds of intellectual property.

Let me give you an example.

Currently speech recognition software is not quite up to the standard where I feel comfortable with using it for dictation. However, it is very good for command-based work such as accessing a menu, highlighting text etc. In fact almost everything that I previously did with a mouse can now be done with spoken commands leaving my hands in place on my keyboard. Should I be allowed to patent that process? How is it different from Amazon.com's 'one click shopping'?

Francis