conversationsAtHive[0]: What Exactly Is A Bug?
conversationsAtHive is a series of posts on our day-to-day technical musings at Government Digital Services while we’re not busy coming up with awesome products. Follow our blog to keep up with the conversation!
So there we were sitting around having some post 9–5 conversations when the question came.
What exactly is a bug?
Disclaimer: wild exaggerations follow, but processes hold.
Unexpected behaviour?
The first suggestion was unexpected behaviour. Does unexpected behaviour constitute a bug? Is it a necessary and sufficient condition?
Let’s put a story to this.
Welcome to the Product
Consider a calculator developed via the Agile methodology.
The Product Owners (POs) have done their due diligence, gone around, done surveys, and observed some behaviours to decide on the first feature to go into the backlog, and…
Addition it is! Addition is the most valuable tool for the masses in this time and age; the Next Big Thing™.
The Sprint Begins
So in Sprint 1, they prioritise addition high in the product backlog. The designers work out a pleasant interface and the developers chug away at the code, creating a ground breaking methodology.
add(firstNumber, secondNumber) {
for(let i = secondNumber; i > 0; – – i) {
++firstNumber;
}
return firstNumber;
}Optimal? Perhaps not. Works? Yes it does. So here’s the problem, the sprint goal has been achieved. What next? They decide to add on subtract() too. Why not? Seems logical.
At the sprint review, they proudly present add() and subtract().
Assuming you are the PO, should subtract() be considered a bug? It’s unexpected behaviour after all.
Possible Outcome 1
Subtraction was next up on the PO’s mental backlog! They are elated and congratulate the team. What a pleasant surprise, the developers managed to get something right in terms of business outcomes! At last.
Life goes on, everyone’s happy
Possible Outcome 2
The people hate subtraction! They’re a positive, forward looking, yet superstitious lot who cannot fathom the idea of having to roll with negative operations. It’s a bug! Get rid of it before it gives birth.
Bug appears in backlog, release delayed.
Necessary && Sufficient
As shown, unexpected behaviour does not always lead to a bug. It’s a necessary condition, but it’s not sufficient. As some developers will say:
“It’s not a bug, it’s a feature!” – a dev, circa 2017
So what’s a bug? We concluded: A bug is an unexpected behaviour that results in negative business outcomes. Neat.
A Bug’s Life: A Human Construct
Together, both example outcomes highlight the human factor as a critical condition in deciding if a behaviour is a bug or a feature.
And is it time for Morals Of The Story? Yes it is time for some Morals Of The Story.
Define Your Bug’s Existence
In Possible Outcome 1, everyone’s happy, but in Possible Outcome 2, no one’s satisfied. This creates possibilities of misunderstanding and breeding of dissent between the business and tech worlds. Not so good for a product team where both depend on the other. Limit your risk by always defining what a bug is, and is not.
As a developer, we don’t like to fix something we thought was never broken; and conversely, no PO likes to have hopes of a golden feature only to have its effects mitigated by an ‘extra’ feature. Defining what a bug is helps to keep everyone on the team aligned on what to expect when doing extra/doing less without full context.
Avoid the Mini Waterfall: Involve Your Developers
Developers aren’t just all about the technology. Lacking context of a feature can hugely impact how it’s designed and developed for users. In the exaggerated example above, it was obvious that the developers had no context of why addition only. In the real world, this happens too at more subtle levels which aren’t always so clear cut.
Avoid mini Waterfall cycles where contracts are passed from one functional unit to another, and reap the true benefits of Agile cross-functional teams: involve your technical team in business decisions.
Keep Calm and Refactor
So the conversation carried on. What if the developers knew that subtraction should not have been done? What difference would it have made?
Assuming they knew not to proceed with other features given lack of business context, the developers could’ve optimised the code. It’s clearly O(n) now, but O(1) would have been possible given some refactoring. Clearing of technical debt is important in any product development. Refactors make code more readable and maintainable, and optimisations make user experiences better, resulting in a more lovable product.
Till Then
conversationsAtHive is a series of posts on our day-to-day technical musings at Government Digital Services while we’re not busy coming up with awesome products. Follow our blog to keep up with the conversation!
Fun fact: applauding will help keep us relevant in your newsfeed. Do give it a try 👏🏽.
