... you will never turn back
(Berlin, Memorial to the Murdered Jews of Europe) – Some weeks ago, when I visited the Memorial, the feeling of loneliness and lack of direction invaded me. I think this is the main achievement of the architect (Peter Eisenman)… bring this feeling to the visitors. And from the position in the picture I asked to myself “What have we learned from this horror?”. Inspired by a continuous learning for a continuous improvement, I would like to make the question applied to bugs and change requirements (CR), but particularly in this post: what can we learn from bugs? We should take them all as improvement opportunities.
Bugs always spot product planning, requirements and implementation weaknesses. But if they arrived until the end-user, annoying and blocking the best product performance and perception, this should be seen as improvement opportunities among different product development phases.
Bugs are extremely expensive for several reasons since the costs to fix them until the customer disappointment cost. About this matter a lot have been written but I like particularly the summary of facts collected in this post: Financial Cost of Software Bugs
Bad or incomplete requirements often drive us into wrong interpretations about the desired features. That’s why roles like requirements engineer, business analyst and UX engineers are so important to be brought into the project in a very early project exploration phase. Quick prototyping techniques (interactive or paper based) can be very helpful to build a common understanding before to start the coding phase.
It can happen as well inefficiencies or mistakes in the solution design or architecture and once the product is deployed in an existing context or ecosystem, bugs or inefficiencies will be spotted.
The solution design and architecture done or approved by unqualified people can also be a reason to don’t spot in time future problems. Unfortunately it happens often, specially in big organizations, important architecture and solution design decisions are taken in a management level and expert opinions are not deeper taken in consideration.
Coming from a previous post, Bugs, change requirements and the PO dilemma, I started to organize some thoughts about what can we learn from bugs and change requirements but specially how can we reduce the risk of bugs in each requirement level.
What can we learn from bugs?
We must reinforce quality, test coverage and test automation, aiming a continuous testing practice, reinforced by the introduction in several levels automation testing.