Maybe not for Kim Jong Un, but for me – yes. Yes it is.
When working on projects there’s constant pressure about launch dates:
“When are you going live?” “Is the product ready yet?” “Still not there?!”
If you’ve been involved in software development projects then you’ll have faced these questions, you’ll know the score and you’ll know the lifecycle.
Build. Test. Implement. Or even better if you work using a more iterative methodology: build (just a little bit), test (at the same time), implement (the little bit that’s ready), then start over and increase the value of the product over time.
It’s during the testing part that the magic happens. This is where the quality of the code gets challenged. Does it do what the stakeholders want it to? Does it meet the requirements? Can it be used on different devices? Does it stand up to high volume of traffic? Does it stand up to potential hacks? etc, etc…
It’s where quality of the development shines through. Or not. But one thing’s for sure, there will be bugs. There will always be bloody bugs.
Sometimes just a few. Sometimes a few dozen. Sometimes a few hundred. And so the cycle starts. Defect analysis. Defect calls. Defect prioritisation.
At this point it’s really easy to get distracted. To get bogged down in the low level details and lose sight of the prize. To get obsessed with trying to resolve Every. Single. Damn. One.
Because of that, this is the time to start to be super pragmatic and start asking some interesting questions.
Like – “What ratio of customers is this defect going to impact?” Or “Can we still make money if we went live with this defect? Or even better ‘Is the risk of going live with this defect, biggger than the value of us learning how customers interact with the product as soon as possible?’
But tred carefully – if the question becomes ‘Can’t we just pretend we didn’t see it?’ that’s shady (and yes, it happens).
Or ‘Don’t log that defect till after we’re live and then we can raise and fix during warranty’ that’s super shady (I’ve heard this first hand).
If you have a whole conversation about it and then someone asks you to forget you ever had it – that’s mega shady.
Or the one where someone states they don’t care if it’s the right thing for customers or not – that’s über shady.
Powered By the Tweet This Plugin
Your professional integrity (and that of your team / organisation) is something precious. Once it’s lost, it can never be regained. You need to protect it with your life. There are some things that you can compromise (like the number of bugs you accept the risk of going live with), but your integrity? Never.
Each situation needs to be considered in it’s own right. Each defect needs to be considered in it’s own right. Obviously you have to ensure you are legally compliant, and meet the standards set by regulators of your given industry, but whether or not you are using the right colour blue for a button is up for debate.
The bottom line should never be that you have to resolve all defects just for the sake of saying you have no defects.
It should be about:
delivering value to customers early
learning as soon as possible
generating income for the business
applying common sense
being accepting that things are never perfect first time round, and that as time goes by and we learn and improve, so will the product and the quality of the code
about being good enough
So back to the original question: Is it ever ok to go live with defects?
In my opinion – of course it is.
What do you think?