The Mean Time to Failure Software View a.k.a What the Hell are We Doing?
What the hell are we doing? As a software professional I am very frequently asking myself that question. I'm not certain we know. Or maybe we know but we continue on anyway.
Today I have a general dissatisfaction with the world of software development. I assume it's not just today that I have this dissatisfaction but in general that I tote it around on my back. I have not put enough thought into it to confirm that it goes beyond a momentary malaise.
As a consultant and especially as a consultant that spends a lot of focus on the 'process of software' I see some ghastly actions. Let's be honest. I perform ghastly at my own times as well. So do you!
But we don't talk about that. None of us. We talk about someone else, or some other organization's ghastly actions but somehow always leave ourselves just outside that circle.
Come on in the water's fine!
Agile embraces change. Scrum embraces quality improvement. Where's the methodology that embraces downright '*** ups' and the school of hard knocks. I think we allow ourselves a world of denial to go swirling around us. It's as if software is built in some role playing game where when it gets slaughtered we just move on to a new character avatar or resurrect that player with all it's flaws and hop into another part of the world. Ughhhh!!!!
I propose a new outlook on software called Mean Time To Failure (MTTF). The basic tenets are:
- Many software projects fail
- even Agile (you just have a more sophisticated denial mechanism)
- Many of the projects that don't fail come out maimed
- Projects that make it out alive have had the definition of success redefined
- This is not a bad thing
- This is essential to keep the MTTF from being 0
- We must plan for failure of delivery or acceptance all or part of a system
- The plan for failure must be very discrete with discrete actions
- Failure is not always acute
- Everyone is to blame
- No one is more to blame than another
- this is at the organizational and personal level
- there are no heroes
- We can't predict for squat
- There are too many variables
- Every person involved in the project increases the inaccuracy by some factor
- Any organization who says they can nail a quote and deliverable and come in on time and budget on any quote of any significant size has only learned how to creatively fail and obfuscate
- The more individuals that want more features and more promises and at specific budget requirement create an curve that asymptotically approaches 0 for MTTF
- Fixed features, fixed bid that exceed more than a few weeks of projection have a MTTF very close to 0
- The insanity must stop
We must begin to speak, up front and candidly, about the real macro level risks in software development. We must state that we think this project has some likelihood of a being on the friendly end or the ghastly end of the MTTF curve. We must have a plan for what to do when it fails, how to mitigate failure but also an acceptance that failure is an option. It is. Failure is an option. It's a force of nature and failure will occur because as mentioned - there are no heroes. We must admit it's an option and plan accordingly. Then when it fails don't just try to fix it by doing the same thing or something worse (something taking you farther down toward 0 on the MTTF curve). Instead, admit failure and re-plan. Re-plan for a better MTTF and admit that this may fail as well.
I don't see this being a widely adopted approach. What do you think. ;-)