Bug Scheduling? But The Due Date is… Yesterday!

Tempo de leitura: 5 minutes

How can one balance resources between the development of software products and their maintenance? Use simple math, don’t hold endless meetings.

Picture this: another day and I am with a great R&D team for one more promising consulting engagement. I am surrounded by smart people, great collaboration, high commitment, care for their customers – great things established! We are just starting to discuss how to explore some opportunities to improve productivity and the questions pop up: “How should we establish priorities between bug fixes and the development of new features?” “What percentages of our resources should we allocate to development and maintenance?” “Should we do the new features the executives are asking for or fix what customer support is yelling at us about?” These are questions I have heard hundreds of times, where too much time is wasted, because… well, they should not even be asked in the first place.

Bugs drive customers crazy. Just as they do to you and I (just remember the last times you lost time or a piece of work because of an application crash). Now, think of a mission-critical app – crashed! An end-user calls the software provider’s support team and someone politely apologizes and tells him the defect will be fixed in a month. “Are you crazy?”, is what the support rep hears from the other side of the line. “Ok, we will do it for next week,” the support guy says reassuringly. “What?!” The customer then is told he will get the fix in the next day. “You have got to be kidding!”. After some discussions between the support rep and the R&D team, the customer finally hears “Ok, you will get the fix at the end of the day today.” “Just at the end of the day?!,” shouts back the angry customer. Something sounds familiar? No date for fixing a bug is soon enough because bugs should not be there, regardless of how you might explain software complexity, impacting factors and blah, blah, blah!

If bugs should not be there, then people should not discuss dates for bug fixes. Due dates are automatically established at the moment a defect is identified: yesterday. Fixes are late from the moment bugs are informed. The only thing left to do is to fix them – immediately. Someone should be on top of any bug in the same day (or in the next day) they are verified, regardless if they are of high severity or not. To accomplish that, any company needs to allocate a certain amount of resources for maintenance. Not any amount, but the right amount of resources. It should not be defined by feelings, guessing, or top-down determinations, but by proper calculations – the number of bugs, medium time to fix – and then the required number of hours or people to be allocated. The result is what one needs for product maintenance – not less, not more.

Surely developers, managers and top executives want less effort spent in product maintenance and more put into new product features. That is understandable, but the only way to it is generating fewer bugs during product development and breaking fewer things in product maintenance (on average, unstructured environments for commercial software put two bugs into products for every three they fix). Thus, if someone has one hundred people in her software engineering team and all she needs is five percent of their time for maintenance, congratulations. However, if she has only twenty people and needs fourteen of them dedicated to maintenance, then I am sorry – seventy percent of the entire team will be required for maintenance. The solution for such a terribly high demand for maintenance is to do a better job at not generating more bugs.

But not everything has to be grim about high maintenance scenarios. Once you have the required resources allocated for maintenance (and the remainder for product enhancements, not the other way around), you will fix defects as fast as they are reported. The time wasted in discussions, priority lists, interruptions, and escalation calls will be saved and used to fix more bugs. A virtuous cycle will be established. With such an improved process, by which development activities generate fewer defects and maintenance tasks don’t break other things when fixing bugs, soon you will have more and more time and people moving from maintenance to the development of new features for your products. Finally, happy customers will generate more revenue, what in turn will provide you with even more resources for further product enhancements.

(Yup, I will tell you: the best development organizations in the US and Europe spend less than ten percent of all R&D effort dealing with and fixing defects, paired with development productivity that is consistently higher than average.)

Ernani Ferrari is a consultant and the founder of the Boston-based firm Mondo Strategies (www.mondostrategies.com) and specializes in business performance in the software industry. He serves many small, medium, and large companies (including corporations such as Microsoft, IBM, and Wolters Kluwer), is a frequent international speaker (PMI, AMCHAM, SQE, IBM, etc.), and is the author of several articles and other publications for this market, in different languages. Ernani has helped over 100 companies around the globe improve their business performance.

Contact: ernani.ferrari@mondostrategies.com. Skype: ernani.ferrari

Have a question? Please feel free to send me an email – I will be glad to reply to it.