I remember reading about the Boeing 787 (the Dreamliner) being designed. I was fascinated by the process and excited to fly one. I finally did and enjoyed it. Since then, I try to fly on those when I can as the spacious ceiling and other changes seem to make for a better flight. I impressed with the work they did and the scale of the changes, both in manufacturing and software. There's a short timeline here and if you ever get the chance to take a tour of the factory, do it. It's very cool.

I fly a lot. Last year I took around 50 flights on airplanes, some of them Boeing, some Airbus, some 737s, 777s, 787s, A350s, and a few others. I haven't flown on a Boeing 737-Max 8, though I did just recently fly a 737-800. When a few of those planes crashed, I somewhat chalked this up to pilot training and a lack of options on the planes. I'm not exonerating Boeing or the airlines, but I wasn't personally concerned. I saw an interesting piece at Vox, but was still curious about the issues. After all, I'm in software, and I fly a lot.

There's an analysis of the crash from a software developer at the IEEE site that's worth reading. It's a look at the issues, the potential ways things could have been addressed and, perhaps most importantly, the idea that our software is not necessarily going to fix problems. Software is a way of reading data and then affecting changes in the hardware, but software isn't perfect. One of the quotes in the article puts this in perspective for me: " Every time a software update gets pushed to my Tesla, to the Garmin flight computers in my Cessna, to my Nest thermostat, and to the TVs in my house, I’m reminded that none of those things were complete when they left the factory—because their builders realized they didn’t have to be complete."

Data matters, but as we all know, data is sometimes incorrect, jumbled, or otherwise problematic. In this case, not only does it appear the data could be incorrect, but the plane software isn't looking at all the data, and it certainly doesn't take all the inputs from the pilots. While humans make plenty of mistakes, they need to have inputs and overrides in software systems.

I don't want to get caught up in the issue with these planes, but rather look more generally at our systems. DevOps looks at the idea that we don't know everything about how to build our software when we start. We definitely know it is not complete and will need more work when it leaves our factory, but we also know that this is the case. We know it's not complete. We take feedback, learn, and adjust what we do. We constantly drive quality up, or at least, that's the goal. Money and politics can get in the way, but the more they do, the less you're doing DevOps.