The uncomfortable reality of software engineering

I am haunted by the idea that someone will have to go back and make changes to certain pieces of code that I wrote in the past. The last time that actually happened was on a project that was originally set up as a demo, rife with technical debt as non-technical managers made rapid changes to requirements and promised clients they’d have something to show that same day. Enough of those types of changes and your project suddenly turns into a duck-taped train wreck. No one can read your code and understand how it works, and eventually, you can’t do it either.

I chat with software engineers in all manner of disciplines and this reality is very much the same. Maybe it’s because engineers are working with a management team that doesn’t want to take the time to do things right, but sometimes it’s due to a tired engineer who didn’t sleep well the night before and just wants to find the first fix for a bug that will get him home by 5:30pm. Sometimes it’s more insidious: individually, every feature might have been put into place with proper consideration, but an edge case causes a catastrophic failure once it runs through all of the machinery.

You don’t see that edge case ever properly discussed in the news. It’s too nuanced to make a good story for the general public, and companies are reticent to talk about major problems with their software. Neither United Airlines nor NYSE have given any sort of technical reasons for their major glitches last week, but that says a whole lot in and of itself: it wasn’t some sort of concerted cyberterrorist attack, it was just an edge case that finally hit the software where it shouldn’t. Maybe it was just that Mr. Null booked his first ever United Airlines flight.

Maybe this is all a reality of software engineering and will be forever, but I doubt that. I think we as engineers are approaching our Arthur Andersen moment. That point where we try to hold our hands up and say that we did what was expected of us and couldn’t possibly do more, but the world will disagree with us. Maybe it’s time we started thinking about how to prevent that moment before it happens because our stakes are much, much higher than the accounting profession’s. No one died because Enron fudged some numbers. They might die if one of those software bugs hits something important: something like an airline.