Sonntag, 16. August 2009

Errors a long time ago

It is not always necessary to fix an error.

When I was 19 I worked for a very large enterprise (in the fields of electronics). I was an operator for the mainframe. I sought this type of job deliberately because I wanted to be near a computer.

There was a special program that had to be run each month. It was called OP and dealt with reminders and demand notices. Normally, it ran for eight hours and it was a nice program. You had to insert about one foot of punch cards. The program used to run without interaction. Every half an hour you had to go to the tape room and change tapes.

Except for one additional interaction. After around 4 hours the program halted.

(Actually, this happened during a sort. The programmers who had programmed the task had done so in Munich where there were six tape units. In Vienna there were only four tape units. It was a kind of a "scaling-down"-bug of the sort-and-merge-program. I got this knowledge many years later.)

In order to continue one had to toggle in some register values on the console. The numbers were displayed with 4 lamps, displaying the value in excess-3-code.

Then one had to toggle in a restart address and with the pressing of the RUN-key the program continued to its end marvelously. I remember that I was stunned when I watched this procedure the first few times. It was not written down anywhere. The information was passed from operator to operator.

I did not think I would ever be able to manage the entries. I was much to frightened that I could possibly do anything wrong. As you can imagine, it did not turn out a real problem later on.

At that time I did not understand why this bug wasn't fixed. I considered it a risk, when human beings had to interfere with batch programming. (Everything was batch in those days.) Actually, there was plenty of room for embezzlements or fraud.

Today, I understand. I try to convince people that errors in software are inevitable, but I also teach the Juran-curve to them. I could easily justify today why the error was not fixed in those days.

Would you believe that there are still programmers running around that believe they can produce error free code?

Samstag, 15. August 2009

What a strange blog title

almost 40 years of exposure to software and testing. Even when I sold grand pianos I had to deal with test. There are some similarities when comparing the testing of pianos and the testing of software.
Nowadays I earn money by telling people how and what to test.
So far as my background is concerned.
In 2008 the profession of the software tester was officially recognized. Until then testing software was not a profession. It was a necessary deed. Disliked by the people who had to pay for it and disliked by some people who were forced to test.
-
Since more than ten years there exists really good literature about the task of software testing. When I speak to some companies and their IT-people I am amazed about the misconceptions that still adhere to software test.
-
The misconceptions are easy to understand. There exist quite a number of test gurus, test consultants and "school founders" that somehow act like religious fundamentalists.
-
Sept 11th has changed many things in life. Money for the IT is not spent as freely as it used to be. Why don't we skip test. It costs only money. Why don't we relay on customer testing as Microsoft has shown us in the Nineties?
-
Lie #1: We don't need test in the software business. Developers should rather learn to develop programs that will approximately work. It is thinkable that software testers find bugs that the customer would never have found.

What do you think?