I like the term “shit be broken” it has some significant advantages when dealing with situations where you have to use it.
As an example, when the inevitable event occurs walking into a meeting of not technical people and explaining “well technically we can describe the issue as …., we can go into more specific if you like but fundamentally that is the problem” focuses attention on what should happen next.
If you work in an environment you can always make it a TLA and say SBB!
At Coroma, I have the privilege of leading a delivery team for Salesforce and Internet related technologies – our team has, more or less, hundreds of years’ experience in this area and we have seen many, many examples of SBB events. This experience guides us in taking the SBB event to an SBF Event (Shit Be Fixed) and that is critically important.
When SBB events occur, many organisations perform Event Analysis, Architecture reviews, Solution Architecture analysis, Code Review, Test Strategy realignment, augment automation testing, review use cases, perform root cause analysis, update test suites, review regression test plans, etc. While I’m not suggesting these are not worthwhile exercises they do not reduce the time between SBB & SBF.
Organisations conduct these exercises because fundamentally an IT department is change resistant. Change in any “system” incurs risk, the more complex a system the greater the risk of unforeseen consequences. IT Departments have therefore minimised risk by performing complex and time-consuming analysis and by resisting any change to this system. Business on the other hand, now demands change. In short evolve or die.
It is a constant frustration to me, to see IT Consultants and Professionals recommending and endorsing (especially in the wake of an SBB event), that we need to slow the delivery of change, analyse more, test more … when this is actually the largest part of the problem.
In the 90’s the businesses that drove the internet revolution, the successes of that era, were businesses that accepted the difference between perceived risk (in a SBB Production event) and the actual business risk of not innovating. They chose a path whereby they limited the time between SBB and SBF, using tools such as Alpha & Beta Testing, Agile and Continuous Delivery. Where does LANtastic & Novell sit in comparison to Microsoft, what about Sun & Compaq as the easiest examples of the differing approaches.
The organisations that waited for the right time, when all features were in place, when everything had been tested and regression tested prior to a full production release – those businesses don’t exist.
Once you introduce an IT culture where you are resistant to change, you are no longer realising return on investment. The natural business response is then to push more and more changes into each “project”. IT despite driving change for the last 40 years, is now the single biggest resistor to change – and in a market where E-Bay can sell and deliver worldwide, this resistance will drive organisations out of business.
So … when SBB happens, it’s not the end of the world … but it will be if you don’t implement a culture and systems that allow you to minimise the business impact and timeframe between SBB & SBF.