Bug Fixing Is Not A Chore
Software bugs are an inevitable part of one’s job when writing code. Overconfidence, negligence, or rushing to meet a deadline or poor planning, or just pushing it down the road are among the main causes of bugs. Fixing them is mostly seen as a chore rather than task someone wants to actively do.
More often than not, bug fixing is associated with those chores that nobody wants to do but they have to do because of company policy. One way companies attempt to tackle this chore is to make everyone equally miserable by rotating the developers attending to HelpDesk. The chances to fix a bug that you introduced are narrow and the chances that somebody else will fix the bug rather than just apply a quick-fix are even narrower.
Another popular approach is to give Friday, either the whole day or only its afternoon, time for developers to fix bugs. You have to very naive to expect any kind of positive results from this approach. Fridays are the least productive time of the work week and yet the company expects from its developers to tackle complex, edge case scenarios. This activity requires a large amount of energy to focus on details that either you, or even worse, someone else missed during implementation when all the context what still fresh in your, or their, brain.
Such energy is scarce during the best days and on Fridays is practically non existent. To make things worse companies usually see bug fixing as a time consuming activity that gets in the way of new features for new customers for more revenue. Without resources and without support but with high expectations from them to make their software working perfectly, developers are put in a though spot to deal with such a critical activity.
To protect that valuable energy, companies resort to very inefficient strategies like using the people in more junior roles or the less productive members of the team to take care of bugs. How can you put in charge of fixing a system someone that cannot think that system from the ground up. The ability to reason about a new system is the same needed to understand it. And because software bugs are not caused by faulty pieces, but by unhandled edge cases, it doesn’t benefit from ready to replace parts. You just cannot train someone to just handle those replacement situations.
The reason I say bug fixing is a critical activity is because it requires a software developer to learn the business context, understand out why the current technical decisions were made in first place, figure out what the solution, not the bandaid, is and finally write the implementation. During this, that person learn more about the project, the business rules, develops better technical skills and will know what to avoid in the future. Absorbing all this information cannot be done on an almost empty energy tank. And neither can be taught as every situation is a new one.
Sharing the lessons learnt from those important cases should be a required aftermath activity. It helps clarify all the thinking that the person went through while solving the problem, brings transparency and improves the planning process, might mitigate the pressure from the business side by showing how costly a mistake can be and, least but not last, it will provide a good source of learning materials for the entire team.
I argue that bug fixing should be treated as a first class citizen because there the long term benefits far outweigh the short term detour from adding more features. First, it makes the entire software application better. Second, there are more lessons to be learnt from practical implementation than courses. Third, it forces the author and their colleagues to reflect their decisions. Fourth, new feature will need less refactoring down the road to better decisions from the get going.
Change your perspective from “Ugh, a bug to fix” to “I fixed bug and this is what I learnt” to reap all the benefits.