Back home, safe and sound

I'm home. It's a wonderful feeling to arrive anywhere, where you're welcome. But coming home after two weeks, there's nothing comparable.

Everything went fine on the trip until London. The flight from Heathrow to Dusseldorf was first announced to be one and a half hours late, which later changed to a full two hours. The plane was coming from Milan, which had had a strong fog so that no planes got out of there until later in the morning. So we left at about 12:30PM, right after lunch time. Arriving in Dusseldorf had its problems, too. The flight in itself was fine, but somehow the staff managed to forget to unload half of the luggage! Imagine that, people are waiting for their luggage and a lot of it arrives. The band goes around and bags are arriving. Some people are happy, get everything they are expecting and leave. Some like me, get half of their luggage and the rest get nothing and are left wondering, what has happened when the band stops. Slowly everybody goes to the Lost and Found office of British Airways to make the paperwork so that the lost luggage can be sent to the right people. The official start making the first forms and after five minutes one of them notices that there are so many people waiting outside their little office, that something must be wrong. This isn't normal. So they make some enquiries and they find out that one whole container has been forgotten to be unloaded from the plane.

So it was back to the band to once again wait for the lost luggage and best. I think that after the rest of the luggage arrived, there were only a normal number of people whose luggage had been lost, standing in line outside the little office. That kind of standardized thinking can often be linked to regular processes and routine situations, where you can use your past experiences to estimate the expected outcome beforehand. In this case the officials must have known (although they didn't explicitly count anybody) that maybe only about six people in the worst case should be complaining after a flight. Probably it is an exception to lose one's luggage. So when they noticed that more than 20 people were coming in from the same flight, they knew to make something extraordinary.

In manufacturing industry they use standardized tolerances to measure every umpth piece to see that it is within limits. If it is too small of too large, outside of agreed, something in the process has gone wrong. Maybe the raw material low on quality or the machine that made the piece is broken. Something is wrong.

In the software industry, this has not generally been possible. Most of the times the problem is with repeatability. How do you set limits, when you always do completely different kinds of software. Each piece of software accomplishes a different task, works in a different environment or is in some other way unique. How could you set limits? The answer is to take big enough samples and not focus on the details. One way is to use the "Tick-The-Code" Inspection method and measure the quality of any manufactured module. Now, you might not be able to set completely precise targets for tolerances, but at least you can say if a piece of software seems to be "Good-Enough" or if it better fits in a category called "Rewrite". If you inspect modules regularly, you can note the results and make a database of historical values, which shows the quality level of your organisation where it really counts, in the source code. That is your bottom line!