Remembering Our "Why": Lessons from the Challenger explosion

Photo Credit: NASA Goddard Space Flight Center

I always remember the anniversary of the Challenger explosion.

It has stuck with me as a sad day, not just because of the deaths of those on board and the reminder of the darker side of being an adventurous species.  But because there was evidence that they shouldn't be launching at all in weather that cold.

This evidence was presented prior to launch by an engineer, Roger Boisjoly, who worked for a NASA contractor Thiokol.  NPR released an article almost five years ago, shortly after Roger Boisjoly's death.  He and other engineers forcefully argued on January 27, 1986 to delay the launch, but NASA was "appalled" by the recommendation and the Thiokol management overruled the engineers apparently under the pressure from NASA. The launch proceeded as scheduled the next morning.

"Then, a few seconds later, the shuttle blew up. And we all knew exactly what happened."

 A few takeaways from this awful series of events that have impacted my career:

• Find a place to work where management behaves with integrity
• Find a place to work where management trusts the expertise of its engineers and will defer to their reasonable recommendations and predictions concerning this expertise
• We need to be attuned to pieces/features that are subject to failure and creatively think about the conditions under which they are likely to fail, especially when they're similar to conditions that the end user will be experiencing
• Communicate with my management and other internal stakeholders clearly about risks I see and speak with as much emphasis as I feel the risk is worth.  I do my best to let things go that ultimately don't matter so that I'm more likely to get their attention when it does.  
• I have never needed them and I don't foresee needing them in my current position, but I have a few extra levels of freakout in reserve for "this could kill people" or "this will likely kill people", where I imagine myself trying to change the minds of those in charge of a NASA launch/no launch type of decision at various temperatures. 

I hope that customers, management, and engineers keep the lessons that can be learned from the Challenger explosion in mind as our work becomes more prevalent in life vs. death situations like driving and medical diagnoses.

A "Post-Agile" Post: "If it works, do it. If it doesn't, don't".

I like simple rules of thumb. I found an article this morning with a very simple approach to the software development life cycle: "If it works, do it.  If it doesn't, don't".

Of course, it's not exactly that simple.  What does "works" mean?

I would define "works" as delivering products that people want to pay money for at a high enough quality to meet the business value of the customer and the ethical standards we should value as technical professionals.

Underlying that is customers are paying enough money in relation to what the software company is paying its workers.  So on the revenue side, we need

• Good market research people.  
• Good sales and good marketing people.  
• Good customer service folks. 

All are making sure that we understand the problems customers are facing and that the customers are and feel valued and heard.
Also underlying the simple approach is we are efficient at delivering the software on the cost side. 

• Development/QA and product management work super closely together so that there is no question what the customer wants and why. 
• We only deliver what the customer needs or have strong evidence that they want.  
• Developers are all focused on current customer needs, paying down any technical debt that's accrued in the past that threatens the current value of the product, or researching future technological trends -- what customers don't need now but will in 1-5 years.  
• QA is empowered to ask questions from the beginning and in a position to find issues quickly after they're introduced.  This prevents Development/QA from having to spend time identifying, fixing, patching, and retesting issues after the initial release.  
• Nothing is done without the customer in mind.  No documentation that doesn't directly serve a customer or promote good understanding of the product within the company.

We still need continual, honest assessment of what we're doing that's "working" and what is "not working".  But by taking the simple approach we focus less on blindly following and enforcing specifics of a process (even an Agile process) and more on the understanding and internalizing of what "works", particularly how each of our roles and interactions contribute to the value of the product.