An acquaintance recently took up an assembly line job with McLaren automotive — the people who make F1 and luxury sports cars. Before this gig, he used to work from his garage doing custom body and paint work, and developed quite a reputation for skill and quality. Working on the assembly line pays better but he is not very pleased with the monotony of it: all he does all day long is fit one small body panel on the chassis. The panel is part of the front wheel arch and it costs about £7,000.
One day a panel didn’t fit properly. It was off by a few millimeters, nothing that my guy could not fix in a few minutes of careful sawing and sanding. To his surprise what happened was very different. That chassis was taken to one side and work on it was suspended for days while a whole bunch of engineers tried to figure out not how to fix the problem but why the problem happened in the first place. My friend, the assembly line worker, put it down to the stupidity of engineers and the bureaucracy of management. In the end he was not informed how the problem was solved and what the investigation uncovered.
My friend was quite obviously an accomplished hacker. His hacker mentality would have fared quite well in software production, where debugging is part of the normal workflow, but was out of place in a conventional engineering setting. His story made me reflect on the huge gap between car and software engineering.
I wonder how many years until software production will reach the level of maturity where we don’t just fix bugs but, when bugs happen, we stop in our tracks, shocked that bugs happened at all in the first place, and only proceed after we had a serious look at our processes. I wonder how many years until our software will look like this
rather than like this