Bug counts as (bad) quality indicator.

The dev team at my company has a Agile approach to software development. So my toughs here are about what is working and why and what not, but this always depends about the context.

 

I'm going to define a bug, as a story written in the bug tracking system, with reproduction steps and observed vs expected behavior.

When we open a bug, we are using is as an artifact, as a tool to communicate stuff to do, stuff to fix.

When a important issue is detected, it gets fixed as soon as possible, maybe without opening a bug. The priority is to get the expected result back again, as soon as possible. Sometimes, it is because a bug. but this also happens because of bad configuration or bad usage of the tool. We really don't care so much, because the priority is to get it fixed.

If the bug is not so important, for whatever reason, then we open a bug in the bug tracking system. We do this so we don't forget to fix it for the next release. This allows us to go faster, to take some risks so we are able to deliver the features as fast as possible, we measure the risks and we decide that if it is good enough to go, but some minor details are worth to get fixed, we ship it first and we fix things later. This is buying technical debt, but we consider that the release has higher priority than the fix off all known bugs, this is why we open bugs, but it is also how we get a new release every week.

So the exact amount of bugs opened is not a measure of quality, it is just a list of known things that are worth to fix but are not a threat to the business.

If we punish the dev team with bug counts, we are going to spend time on sterile discussions about if a bug is a bug, or a feature, or a bad usage, or plainly who to blame, and we are also going to tailor our results depending on what is being measured. But we are not going to get more quality this way.

If we use the bug tracking system to measure the quality of the team, we will be perverting the core function of a bug tracking system, this is, to solve the known bugs.

By doing this way, the team has a clear goal, it is to get the new features out, running and adding value to the business, making the user experience better than it is today, and not lowering the bug count.

These are not only my ideas, but I wanted to make a short writing. If you feel like reading more, please take a look at:

Cem Kaners writing , Joe Strazzeres writing, Michael Boltons wrtings here and here

What Carles Climent learnt when he left Aureka.

I might not be very good about writing things by myself, but from time to time, I find nice posts that I would like to share. Let me introduce you to Carles Climent and his blog. http://www.carlescliment.com/

I first met Carles Climent one day he was hosting a talk about quality in software development. The talk was in Aureka, the company he was working in. It was a nice talk, where we talked about testing and quality.

Carles had the initiative to host such a talk, so as I respect people with initiative, I started following his blog.

Last week he wrote about the lessons he has learned, he produced such a nice post that I'm about to share it with you.

About the process:
- Software developing is a human activity, so the trouble that a development team faces use to be human problems, and the solutions for those problems, should be on that field too
- Process is worth in the way they are considered a process. If you forget why, or you don't understand why the process is, this process could go against you.
- Agile methodologies are nothing without agile mindset
- Like a bullet, once you fire an email, there is no way back for it
- Everything is questionable

About people:
- Nobody can change other people. Not motivation, or opinion, or the way they work, no matter how many facts you put over the table, at the end, there are individuals who choose to change themselves.
- It is very easy to hurt other people's feelings, and that negative actions bring negative consequences
- It is better to say nothing that to just talk. It is better to silently make example with the things you do.
- Don't waste time with people that are turning your back, instead, give it to people that brings you a smile.

About Technique:
- TDD is the best finding in my career, at this point.
- Develop is like painting. You correct, you change brush, you look at details from close and to the big picture from far away. It is not a engineering activity, but a creative one.
- When you got no master available, books are quite good, but when we really learn is when we apply what we have readen on the team or on ourselves. Experimental method
and a team as a lab are the true masters.

About Excellence:
- Excellence is the path and not the destination. Every single new thing you learn, uncovers you a whole set of new things you stil don't know about, making you feel very small.
- Passion is a whole, you need to squeeze every moment and drink it's juice. Indolence, commodity, inactivity, are all waste.
- The line between passion and obsession is a thin one, so the key is to hold balance, at stay away from the fire when it is burning... and that is so hard.
- Talent gets thinner without effort. Effort gets into talent.

About the company:
- Everything that goes up, goes down again, and if it goes up quickly, it goes down in stall.
- Relationship between worker and company reached a higher level when there are trust, affection and mutual respect

About the future:
- I'm going to read more, go to the movies, run more kilometers, and have more free time than those last ears
- That it is time to build my own ship, that I'm unfolding the sails, and that there is no way back.

Only thing I can add to this post, is to wish you good luck.