Monthly Archives: May 2015

Is this a feature request or a bug?

How does a bug differ from a feature request?

I’m sure like me you have been in many a heated discussion on whether something is a bug or a feature. In my view a great deal of time is wasted in these arguments that could be spent more productively.  A long time ago I concluded that, at best, it wasn’t a valuable distinction, at worst that to distinguish them is in fact damaging.

Consider the following possible definitions of bugs and stories


Feature Request

A proposed change to how your software currently behaves in the hands of users to deliver greater business value.


Bug

A proposed change to how your software currently behaves in the hands of users to deliver greater business value, which you want to blame the development team for doing wrong in the first place.


Lets think about two important points in these statements

  • “Currently behaves In the hands of users”
  • “which you want to blame the development team for”

“Currently behaves In the hands of users”

If no one can see this behaviour its not done yet. So during story development we should simply adjust and fix things as we find them – we want to get to done not half done, if you need to raise and track bugs at this stage you probably have one or more of the following problems or something else that needs to be addressed as the root cause

  • Stories too big – taking too long – think about how you can break down the delivery of value
  • Working in silos, with lack of integration of QA/BA/Developers/Product Owner’s
  • No definition of done – “In the hands of users” is a pretty good place to start in my book.

“Which you want to blame the development team for”

This really seems to me to be the nub of the issue. When we call something a bug there is an implicit message that the development team did a bad job. My experience is that development teams generally set themselves very high standards on quality that this attitude can damage morale and ultimately lead to lower quality and rate of delivery. Calling things bugs can lead to wrong expectations such as;

  • the cost of fixing it will not impact other work – devs did bad they can make up the time
  • its automatically the most important thing to do which it may or may not be

The “No Bugs” messaging that has been around can also lead to prioritisation of bugs over stories when the bug fix may have minor business value compared to other changes in play.

Given these two definitions is it a useful distinction?

It is my contention that distinguishing bugs from stories adds no value. I have had good success with treating bugs and stories the same once the software is in the hands of users. They both have some business value associated with them and they both need to be prioritised based on that value. So having a single backlog makes much more sense to me. Moreover separating these out into separate tracking systems or even labelling them bugs or stories in the same system is a bad idea stop doing it now!

But people like raising bugs I’ll never be able to get rid of <insert favourite bug tracking software here>?

Depending on your company culture you will find it easier either to call everything a feature or everything a bug. I don’t think it actually matters much, although it can be fun to start a new project with a bug along the lines of “Unable to see login page” before a single line of code has been written. Whichever way you go my recommendation is to pick one and treat it as a single backlog.

A word of caution, if you call everything a bug remember ONLY the product owner should control the priority of the backlog that means sysadmins, customer service etc don’t get to set the priority – sure they get a say but the product owner has to balance all the business priorities and make the call.

Tagged ,

One thing: Abstract till you drop!

A code smell is some characteristic of your code that indicates that something may not be quite right with its design. We can use them to gently guide us towards better, easier to understand, more maintainable code. One smell I have found particularly useful to pay attention to is “too many private methods” (aka Methods should be public). Having many private methods can often be an indication that you are missing one or more abstractions.

To illustrate this I will take an example reproduced here from Uncle Bob’s post One thing:Extract till you drop I think that Bob’s approach here is excellent, as far as it goes, but that to really get to “One Thing” we need to push on by seeing what our extracted private methods can tell us about possible abstractions, and to ensure that not only do methods do one thing but that Classes as well should do one thing our mantra should be;

Extract till we drop

then

Abstract till we drop

Continue reading

Tagged , ,
%d bloggers like this: