Verborgen Gebreken

Verborgen Gebreken
VPRO Noorderlicht / 25 min / 23-11-1997
Goed nieuws voor wanneer uw computer weer eens vastloopt: het ligt niet aan u. Volgens deskundigen Dr Les Hatton en Watts S Humphrey is software over het algemeen van beroerde kwaliteit. Niet alleen voor PC’s, maar ook in betalingssytemen, auto’s, vliegtuigen en waar al niet. Het wordt tijd dat software-engineering een volwassen technische wetenschap wordt. Anders staan ons nog vreemde verrassingen te wachten. Een tragikomedie over computer-programmatuur.
tekst van de uitzending

Tekst van de uitzending:

VPRO NOORDERLICHT
UITZENDING 23-11-97
TITEL: VERBORGEN GEBREKEN
door Jos Wassink
eindredaktie Rob van Hattum

DR. LES HATTON
AUTEUR SAFER C
OAKWOOD COMPUTING
When I left this morning to come to Holland, I arrived at the check-in desk of KLM and all KLM¹s computers were down. So I couldn t check in for 20 minutes. So perhaps it s just me.

IR KEES SMEDEMA
COORDINATOR SOFTWAREPROCES VERBETERING
PHILIPS MEDICAL SYSTEMS
We leven in een software crisis en sinds 1968 zitten we eigenlijk nog altijd in dezelfde software crisis.

DR. LES HATTON:
Bugs are almost a laughable thing. We call them bugs, a diminutive expression, and we laugh about them .

WATTS S. HUMPHREY
AUTEUR Discipline for Software Engineering
SOFTWARE ENGINEERING INSTITUTE
I prefer instead of talking about them as bugs, refer to them as land mines or time bombs.

DR. LES HATTON:
My first professional job was in the 70 s I worked on numerical weather prediction at the meteorological office in the UK and my first job was to leaf through the existing weather prediction programme. And I found a terrible mistake which I corrected thinking this was going to make me famous and it made absolutely no difference to the results whatsoever and I never understood why. As I continued in computational science I got affected by software more and more and finished up studying it in the end, which is what I ve done for the last 10 years.

DR. LES HATTON IN LECTURE:
Good morning everybody,
for the next couple of days I ve got you for ŒSafer C . The course is like a thick sandwich in the sense that in the first part until about mid-morning we ll be talking about software failure generally.

DR. LES HATTON:
There s an engineering saying that states: It s not a sin to make a mistake, it s a sin to repeat one. In most classical engineering, improvement occurs by avoidance of previous mistakes. software engineering has not learnt this fundamental lesson yet.

DR. LES HATTON IN LECTURE:
The ABS system in my car failed three times. The third occasional I narrowly missed the car in front and I stopped the car with the handbrake, which is still mechanical thank goodness. If the car industry ever produces a handbrake driven by a computer, I m walking.
I managed to stop the car. This problem was only fixed when the computersystem was replaced, which controls the ABS. I don t know if it s hardware or software, but either way the fact that an ABS system which is supposes to help you braking failed completely, rather worries me.

JOURNAALFRAGMENT 25-09-97:
Alle Interliners van het model met twee achterasen zijn terug gehaald naar de garage. De dienstregeling is overgenomen door touringcars. Nadat gisteravond een twee-assige Interliner spontaan de staionsrestauratie i Eindhoven was binnengereden. Elf personen raakten gewond: de buschauffeur, buspassagiers en bezoekers van de restauratie.
De bus is uit zichzef gaan rijden. De chauffeur heeft uit alle macht gere,md, maar tevergeefs. De bus bleef een spoor van ravage aanuichten. In Brabant en Limburg zijn al vijf maal Interliners uit izchzelf gaan rijden

DR. LES HATTON IN LECTURE:
Software is literally exploding inside cars. It s growing at a very quick rate.
Electric razors and of course comercial aircraft today, the latest generation of commercial aircraft have huge amounts of code in them. So, a very large amount of software flying around in the air there.

DR. LES HATTON:
There was a very well known incident of a software failure in a Airbus A-340 in September 1994, when an Airbus 340 was approaching Heathrow from Narita in Japan and suffered several software failures including a falsely displayed out of fuel message, both the pilots and the co-pilots main screen going blank, leaving a reassuring ŒPlease wait message on them and the plane turning left in stead of right. A number of incidents which were all documented by the Air Accident Investigation Branch in the UK.

DR. LES HATTON IN LECTURE:
The two most common phrases heard on cockpit recordings in modern aircraft are: ³What s it doing now?² and ³There it goes again.²
There have been descriptions of the use of modern computer systems in aircraft where the pilots are busy typing in a MS-DOS like syntax into the flight managment system: ³Backslash.. is that a backslash or a dollar sign?²
This is not the place for this kind of human interface.

DR. LES HATTON:
Modern commercial aircraft, as well as military aircraft, have very large amounts of software. Several millions lines in the case of the latest generation of Airbus and Boeings. There have already been incidents recorded of software failures in these types of jets and I feel very uncomfortable when sitting in an aircraft driven by several millions lines of software.
If you look around at the defect density in the world, it s relatively rare for systems to get below about 1 defect per 1000 lines of code and stay below that.
So if someone says to me: Œwe have 2 million lines of code , I think: ŒIf you ve done a really good job, you have about 2000 defects. So I m not very happy about flying in systems which are governed by such large amounts of software.

JOURNAALFRAGMENT 04-06-96:
(crash Ariane V door programmeerfout)
Het aftellen begint.

DR. LES HATTON IN LECTURE:
Ariane V was a classic example of an avoidable failure. In fact what happened here was a 64-bit number was basically forced into a 16-bit integer.

This component wasn t necessary in Ariane V. It was just blindly reused. But in its shutting down, it shut down critical components also.

The critical components then occurred in two seperate channels, but the same software was running in each channel. So both systems shut down.

These took down the actuator controls and the spacecraft crashed.

JOURNAALFRAGMENT 04-06-96:
(crash Ariane V door programmeerfout)
De raket heeft z n normale baan verlaten.

DR. LES HATTON:
The Ariane V failure is a well known class of repetitive failure in software systems whereby one object is attempted to be forced into a different kind of object. It s like we say in English a quart into a pint pot; it overflows. So if you study the failure of software systems, you find this kind of problem again and again. It was an avoidable failure, I m afraid.

IR KEES SMEDEMA
COÖRDINATOR SOFTWAREPROCES VERBETERING
PHILIPS MEDICAL SYSTEMS
We zijn een jaar of 3 geleden in contact gekomen met Les Hatton die op uitstekende wijze aan ons heeft duidelijk gemaakt dat er een hele boel vermijdbare fouten zijn in software.
Nou zijn software ontwikkelaars die zijn, die blijven creatief en blijven ook eigenwijs, hebben eigen wijze waarop ze software ontwikkelen en hebben allemaal hun eigen gedachte over wat goed is en fout in software ontwikkeling.

Software wordt niet in je eentje gemaakt maar software wordt gemaakt door een heleboel mensen bij elkaar. Als je een project hebt waarin 500.000 regels c-code, software geschreven worden, dan doe je dat niet op je eentje maar heb je en ongelofelijk grote samenwerking nodig met anderen. Het moet goed en georganiseerd gebeuren en dat betekent dat er heel goede afspraken tussen moeten zijn.

Software heeft heel erg lang in het kader gestaan van iets magisch en de mensen die software maakten waren hele knappe jongens of meisjes die je ook niet lastig moest vallen met allerlei randvoorwaarden.

JOURNAALFRAGMENT 22-10-94
(PIN-systeem ligt plat)
COMMENTAAR:
We doen het zo langzamerhand bijna overal: betalen met de PIN-code. Maar als er iets misgaat in het systeem, dan zijn de poppen aan het dansen.
WINKELIER:
We gingen om half negen open en om negen uur lagen we eruit. Opeens beginnen cassieres te bellen van m n PIN doet het niet. Dan de volgende en de volgende en de volgende. E dan zie je he jongens, we hebben een probleem. We liggen eruit.
COMMENTAAR:
Bij Interpay Beanet zijn 40.000 terminals aangesloten. Op een willekeurige zaterdag gaan er zo n miljoen betalingen via dit systeem. Vanmorgen vielen er drie datacomunicatielijnen uit.

WATTS S. HUMPHREY
SOFTWARE ENGINEERING INSTITUTE, PITTSBURGH, VS
There are known techniques for solving these problems. For developing sofware on time, making quality products, that sort of thing. The problem is: they re not being used.

Over a period I ran IBM software work. I had several thousand engineers and we were building software and I really had a fascinating career with the company and I got close to retirement age, I was were I had probably go and think of sitting, you know, retiring and all… But I didn t really want to go sit on the beach and so I was debating what to do.

And so I was thinking about what would be an outrageous commitment. And it occurred to me that an outrageous commitment would be to change the way the world did SW. Cause we d seen engineering methods that worked and nobody used them. So that s what I decided to do. I would commit myself to do that. And so, I looked around for where to go and it looked like SEI, which was just forming, would be a good place to go. So I retired from IBM and I came here and I didn t know how I d do it, but I decided that s what I would do and that s what I ve been working on. It s been great fun.

The airforce asked us if we could work out a way for them to evaluate who was a good bidder for software. They felt they needed to get good contractors that could do the work. So they asked me to work on that first project. And the light went on. And in stead of going out and evaluate proposals, which is what they had always done, let s go out and look at the process.

The quality of the job you produce is very much a function of how you did it. And if you re look when people do quality work, like sawing up garments or they make pottery or .. they way they do that, or cooking a meal. I mean the way you actually approach it: the raw materials are important, how do you stir it, the way it s done .. The process generates the quality of the product. So that s really the issue.

One might say: well, the hardware people have learnt how to do this. People can build electronics and automobiles more or less on schedule, so why can t software?
The difference there is the source of discipline. The disciplined work in hardware is disciplined by the factory. Because the hardware engineer has to produce a design that the manufacturing people can build. And they got to be able to build it at volume, cost and schedule. And so they ve got to commit to it: they ve got to say: OK, I can build that and this is what it ll cost. That means they know which parts to cast on which machine, what material do you have to use, what s the surface finish like, and how do they fit, what kind of corners. All this stuff, right?

You ve got to know what the weight is, and how do you package it: an enormous amount of detail. So they need parts list, materials lists, drawings and all this stuff. So a design, when you send it to the factory is a great pile of stuff with a great deal of detail. So they ll go through it and lay out tooling plans and schedules and everything.

In software, if you want to manufacture the software, you run another pass on the computer. It s a copy. So what s a design in software? And the difficulty is you ve got to go through all the same issues. You got all the parts list. you ve got all this stuff, what are the pieces, how do they fit together, how do they relate? Change management, all of this stuff that we should use in software, but we don t. And the reason we don t is, that in stead of a manufacturing group that disciplines us, we ve got to discipline ourselves. And self-discipline is extraordinary difficult. And that s sort of fundamentally why its hard to build this discipline we re talking about.

TIJDENS KOFFIEPAUZE CURSUS ŒSAFER C
DOOR DR. LES HATTON

JAN MENTING
PROGRAMMEUR
Vaak lijkt voor de gemiddelde gebruiker lijkt het programma te werken maar zodra het programma in een soort uitzonderingssituatie terecht komt waar-ie goed mee overweg moet kunnen, dan zie je vaak dat daar dingen fout gaan. En het is met name de kunst om juist al dat soort stukken door te lopen en te testen. Daar is geen tijd voor, niet voldoende.

MARK HUISINGA
PROGRAMMEUR
Je kan nooit alles testen wat in de SW gaat. Dat is bijna onmogelijk . Dan ben je zolang aan het testen dat tegen de tijd dat je uitgetest bent met je programma, dan is het waardeloos dan is het niet meer te gebruiken, want dan is het al zodanig verouderd.

BALDOR VAN LEW
PROGRAMMEUR
There are some basic mistakes that we re making, repeating over and over again. And really we shouldn t expect the testers to catch them. We shouldn t be making them in the first place. So I think that s one of the things that hopefully will come out of the course. We can t solve the fact that software is incredibly complex, there s a lot of state in there and given time pressures we can t cover every single state, but at least we can avoid some of the basic errors.

WATTS S. HUMPHREY
SOFTWARE ENGINEERING INSTITUTE
When organisations aren t very effective and they re having problems delivering quality products on time, it s because of the poor quality of their process as I described. So there a whole lot of things you got to put into place. The difficulty is when you look at any organisation you d say here s where you are and here s what a good process looks like, you discover they ve got hundred of things to change. And the difficulty is you can t change hundreds of things in the organisation. It s so overwhelming, they can t consider doing it. They trying to deliver products, they re busy!
And so the purpose of the Capability Maturity Model was to identify at each level of the organisation, you look at where they are, say what are your problems now. So when you fix these two or three things now, it would help you to improve today.
And so the whole idea of the CMM was to identify a set of steps. It s like going up the stairs, you re going go ten steps at a time or four steps at a time. You like to take it at one step at a time. And that s the idea of the CMM to give people a progression so that they can see the stairs. How to get from one to the next, and that s the whole idea.

IR KEES SMEDEMA
PHILIPS MEDICAL SYSTEMS
Het CMM-model van Humphrey is als je er naar kijkt niks nieuws. Het is een soort van common sense, waarvan iedereen al had gedacht dat dat natuurlijk moest gebeuren en wat in een groot aantal andere disciplines ook al is gebeurd en hij heeft dat netjes en begrijpbaar opgeschreven en hij heeft het opgeschreven op een manier dat ook software ontwikkelaar denken: ja, daar zit wat in.

De verandering in cultuur voor de software ontwikkelaar betekent dat hij niet meer vrij is, dat hij niet meer zo vrij is als-ie vroeger was. Vroeger had-ie betrekkelijk slacht gespecificeerde functionaliteit waarmee hij begon te werken en je kunt het voorstellen dat ie als het ware zwemmend onderdook in het water. Niemand wist precies wat-ie deed. En aan het einde van het bad kwam-ie boven en zegt: is dit wat je had willen hebben.
Softwaremakers zijn in zeker zin aan banden gelegd, ja, zeker.

WATTS S. HUMPHREY:
People perceive this as constraining, they see this limiting them. But when people actually do it, they get into it, they discover it s freedom. The thing that s really constraining is all the struggling you re going through in an uncontrolled process. It s really very constraining. People work late nights, they re upset,things don t work, they re refixing things, they ve got problems and they re stumbling over. And that s really constraining.
The discipline is stuff that takes care of itself. It doesn’t constrain the engineer, it just means that the stuff works well.

DR. LES HATTON
I don t think that initiatives like the CMM, capability maturity model, will ever eliminate software defects, just as I think that any other methodology will ever eliminate software failures.
The CMM helps users acknowledge crucial deficiencies in order to correct them and move on to the next level. That s good. But as for any technology leading inevitably to defect free software, I don t believe we can produce such a technology.

Quite frankly, we don t understand the nature of the beast. And as far as I m concerned, building multimillion line systems for example to control critical systems is a triumph of ambition over capability. We don t know how to make those systems safely and I think that if we put such software systems in a very critical situation, yes society is putting itself to risk. It s growing to quickly too soon.

JOURNAALFRAGMENT 02-07-96
(presentatie Marga van Praag)
Goedenavond dames en heren,
er is een techische storing: alle computers op de redactie zijn uitgevallen, alle teksten zijn verdwenen. Daarom kunnen we geen normale uitzending maken. We hebben wat teksten opgediept van Acht Uur en we zullen u proberen die zo goed mogelijk te brengen.

© Het Inzicht / Jos Wassink, 1998

English version –>