It’s not a bug. It’s a feature!

Let’s be honest. You’ve said this phrase countless times. Probably even in multiple languages — at least I know I did 🇵🇱 🙂. We all know how it goes.

1. We need to implement new feature or fix some bugs.
2. After our work is done we ship our solution to a TEST environment to be tested by QA team or even clients themselves (business stakeholders). Then we go home.
3. Next day you see new Jira ticket with Issue type: Bug and priority: Critical.
4. Jira ticket relates to some unexpected behaviour we introduced during our development process.
5. Product/Project Manager asks during daily stand-up what is this new bug.
6. It’s not a bug. It’s a feature! — you respond. The bug is never fixed.

We all have been there. Let’s stop for a while and think what are the long term consequences of not fixing this unintentional feature. We’ll cover all 3 phases of our unintentional feature’s lifecycle:

• Bug
• Feature
• By design

Bug and feature. What are they?

Wikipedia defines software bug as follows:

A software bug is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

As stated before we may introduce bugs on different levels. Sometimes it’s code bug, sometimes whole system design may be faulty. The most important is producing incorrect result. Of course different bugs have different consequences.

On the other hand, in The Journal of Object Technology software feature is defined as:

A feature is a unit of functionality of a software system that satisfies a requirement, represents a design decision, and provides a potential configuration option.

If we look at definitions above we may conclude that the main difference between bug and feature lies in their intentionality. If functionality works as everyone expects, it’s a feature. When system behaves in some unexpected way we call it a bug. Going further: many bugs have the potential to become features when we change how our product or system expected behaviour.

How a bug become feature?

To give it some justice. Not all unintentional features are introduced only by code mistakes. Sometimes we just forget to handle corner cases, some other time we cut corners, and even other time we leave solution open due to some ambiguities. To me these latter are the most interesting ones… Going back to answering the paragraph question:

A bugs become feature when using bugs will produce an expected outcome.

Using bugs as features require deep understanding of a product or system. Our system is designed to solve particular problem. If our clients use bugs to get the job done, everything’s fine, right? It depends on who you ask. From business perspective it’s awesome! We found new business value in existing system, so development cost is almost zero! We can introduce this feature to end users in no time! How exciting! Well, from Software Engineer perspective, not so much.

Bugs becoming competitive advantage

Now is where the fun begins. Using unintentional features allow us to quickly start and validate business idea. It is great. However, after validating the idea we should stop for a moment and think how we will use this bug in the future.

Should we redesign system to build feature with the same output as using bug? Is using bugs introduce new technical debt?

More than often the answer is: Yes, it is.

Did we set alerting policies? Did we asses all the risks and scale?

In my experience, the answers are: No, we didn’t.

Reality is that we do not plan to improve the unintentional solution. From business perspective everything is fine and we can move to another urgent topic or functionality. That’s how another day in IT company ends. Unintentional features are used frequently and more and more often.

Troubles in the future

Software Engineer plays the same rules as every other employee. Leaving company is part of every employee life cycle. The same is true for me, you and our business clients. How it relates to unintentional features? Those usages of bugs as features often remain silent and undocumented. They become urban legends and became parts of the system that no one knows how they work. Newly hired team may want to fix our design flaws and accidentally remove our feature from the system and everyone finds out too late. After the feature is restored there is a need to maintain it. So, whenever we change our technology stack or core features or any other change, we need to take into account our unintentional features. Maintenance becomes pain in the ass and reassembles fixing bugs on bugs. That’s how we get last element on the opening picture: bug by design dressed in a patched suit.

Conclusion

Should we do anything? Is it just natural flow of events? There is nothing wrong with starting quickly. If we can use existing system it’s even better. The main issue is the understanding of the consequences. What we can do is to be a little like Boy/Girl-scout Engineer, but on different level of abstractions. We can document our unintentional feature for team members in the future. We can assess the risks and technical debt and present them to our supervisors. Last but not least we should plan to build proper feature and remove this accidental bug. Future team members will thank us for that.

So, in the end. Can we respond to reported bug: “It’s not a bug. It’s a feature!”?

Answer: Yes, we can if we understand the consequences. Do so with a clear conscience.

Resources

1. Sven Apel, Christian Kästner, “An Overview of Feature-Oriented Software Development”, Journal of Object Technology, Volume 8, no. 5 (July 2009), pp. 49-84, doi:10.5381/jot.2009.8.5.c5.
2. Wikipedia, Software bug https://en.wikipedia.org/wiki/Software_bug