One of the most fascinating documents I’ve read to date is the memo from Roger Boisjoly on O-Ring Erosion. The original target audience for this memo he’d written were the management folks of Morton Thiokol back in 1985, about six months before the Challenger disaster.
What I find so striking about this whole story is its resemblance to the field of software engineering. We software developers can relate to this story all too well. I’ve personally been in this situation more than once. Heck, some of us are in similar kinds of situations all the time.
Roger Boisjoly attempted to halt the launch of the Space Shuttle, unfortunately to no avail. In his particular case, a failure of the Space Shuttle would cost the lives of the astronauts on board. But what about the software that we are crafting? In most cases, a failure of the software would not result in the loss of human life. It would cost the company a particular amount of money. Worst case scenario, its reputation would be flushed down the drain alongside the money.
But what should we do when we encounter reliability issues in the software that we’re working on? Well, first of all, we make an assessment about the severity and the impact of these problems and fix them accordingly. But what if it takes us a couple of days, a week, two weeks or even a few months to fix things? Well, then we usually turn to the management staff, explaining in our best non-technical terms what’s going on and ask them for the time (aka budget) we need. But here comes the tricky part. What if they don’t want to listen? What if they don’t take us serious? What if they don’t trust us that our findings are correct? What if they simply ignore us, wondering why we still have the energy to even come talk to them after or during this dead march that we’re in? What if they do listen to our plea, wholeheartedly agree with everything we say, walk us back to the hallway and then simply don’t give us anything except more business requirements and feature requests?
But now on to the million-dollar question. What do we software developers do when we don’t get the time to do the right thing? Well, we could try to fix things in our spare time, sacrificing the precious time we have with our family and friends or perhaps even our sleep for the next couple of days, weeks, months, perhaps even years? I don’t think that this is very sustainable. Or we could simply ignore management, stop adding new features and business capabilities and start fixing things on our own behalf, like some kind of software development team mutiny? I guess this will end up with one or more developers getting fired. Or we could start a campaign on social media about how software developers are being wronged at this or that particular company. Would anyone even care? And this will probably end up in some layoffs as well.
So what should we as professional software developers do to make things right in these kinds of scenarios? Maybe the people of the software craftsmanship movement could draft a script with concrete actions that guide software developers when they find themselves in the same situation as Roger Boisjoly?
I can only wonder what would happen to our industry if only 10% of all software developers would follow the actions described in such a manifesto. Wouldn’t that be useful advice?
Top comments (0)