A large part of improving the quality of software is knowledge sharing (indeed it is one of the basic tenets of Lean). In most organizations when a bug is submitted it is usually delegated to the developer who wrote the original code.

Paul Pagel’s blog discusses how his team tackles bugs in development and production.

I especially liked:

“[The Production Support Resource] seems a lot like a silo to me. Everyone should be able to do production support on any system. I should have to, because it is a perspective of the system that is important to have. In response to this, we came up with a system of triage. Each day of the week is assigned to a specific developer. If a support item comes up, it is the job of the triage developer to respond to the client/customer we are working on it.”

This is such a simple way of sharing knowledge and keeping tedium away from a designated ‘support engineer’. However, managers may originally question this for several reasons including:

1) A faster response time will occur if the original author fixes the bug. – This is short-term instant gratification. After a while the difference in time for a bug fix between developers (of similar skill level) will most likely be negligible.

2) The author is an expert in that area. – This allows others to increase their skills knowledge, benefiting the entire team. What happens if the original author is out sick or even leaves the company?

3) We’ve always had a designated Support Engineer, everyone knows who to go to. – This is a Command and Control’ management style and in most cases leads to lower team results. Managing by Facilitation and allowing the team to assign work themselves has proved more motivational to the team and resulted in higher quality artifacts.

I strongly believe that this method is more beneficial to the team, evolving individual’s skills and ultimately benefits the customer.