When Features are bugs

The old joke in software engineering is that when a tester files a bug that is too hard to fix, the developer sends it back as ‘working as intended.’  It’s a magical way of making a bug go away – we turn it into a feature instead.  If you have been a tester for any significant amount of time, I’m sure you have experienced something like this.  However, have you ever stopped to think that sometimes the opposite can be true? Sometimes things that we call features are actually bugs.

Now, you might be thinking “slow down cowboy.  If we don’t have features we don’t have a product.”  That is true of course, but consider this quote:

[high] feature count makes users confused (hence it’s a product quality issue) and it adds code complexity, making the code base less amenable to change.¹ 

The idea of quality is a many faceted thing and plays out in many different ways.  This quote points out two things that affect quality, but that we might not always think of as quality issues.  The first is the idea that user confusion is a quality issue.  If a user can’t find the features they want or need, your product is not valuable to them. Adding features that let one user do something, but that obscures things for other users, can be a quality issue.  Obviously it is OK to add new features, but what kind of features can cause user confusion?

Off the top of my head I can think of a few general questions that could help diagnose if a new feature falls into this category.

• Is this feature only intended for a very small subset of our customers? – Perhaps it will hurt more customers than it helps?
• Does this feature fit in well with what our core product offering is?  Is it a whole new type or category of thing?  Does it fit well into one of our existing menus? – If not, we may be adding unnecessary complexity and hence confusion to the product.
• Is this feature overly similar to other features we have?  – We think by giving users more choices we will make them happier, but the truth is too much choice actually can confuse and leave people dissatisfied.²

I’m sure there are many other questions you could add to this list (go ahead- write some down!), but the point is that by taking a few minutes to think and talk about this aspect of quality, we might be able to keep our product honed, simple and less confusing and in the process we will have created a higher quality product.

A second aspect of quality that the quote above points out is that code complexity and the ease with which you can change your code are quality issues.  This is perhaps a less obvious form of quality as we are used to thinking of quality in terms of things that impact customers, but the reality is that a complex, tangled scary to modify code base is a low quality code base.  We may be able to ‘make it work’ for a  while, but eventually it will catch up with us and the quality issues at the code level with leak out to customers.  Every new feature we add increases the complexity of our code and unless we are very careful about the way we architect and add new features, it will become more and more difficult to respond to the changes our product needs.

The point of this all is that features have a cost.  They don’t just cost you something when you create them.  They continue to have costs down the road.  Maintenance costs and repair cost when things break, and monitoring costs to make sure they don’t.  When you buy a new car you know you will have to spend money on upkeep, and you know you need to check on things once in awhile.  It’s the same way with adding new features.  There are ongoing cost associated with them.  Make sure the feature you add is valuable enough to pay back those costs.  Don’t just add something in because it’s easy to do. Think about the long term costs.  To change the metaphor, don’t buy a house and then realize you can’t pay the property tax and mortgage on it.
A feature that is working as intended might still be hurting the quality of your software.  Don’t let the fact that it is working as intended stop you from pursuing a high quality product both you and your company can be proud of.

Footnotes

1. Quality of Qualities
2. Paradox of Choice