This debate isn’t new, this discussion isn’t new and I won’t pretend it is. The argument between bug and feature has spawned a lot of opinions from a lot of people who want to simplify the question.

Why does it matter? Because how we communicate internally matters a great deal.

Features: 

Features are things we haven’t tried before. Completely new code and functionality. It’s not hard to define, if you’re going to create whole new methods to accomplish it, it’s probably (but maybe not always) a feature.

Why it matters?

Because features are both billable and require a significant commitment from the whole process, including brand new automated testing, potentially new database work, brand new requirements gatheirng.

Features are usually the most expensive type of software modification. That means that in companies where money is important features usually need the most consideration of cost vs. gain.

Enhancements:

Enhancements are modifications to the behavior of existing functionality. You have a list and you want to change the way it sorts? After save the page redirects to home instead of show? These are enhancements to the existing workflow.

Why it matters?

Enhancements are nice to have, generally they fill in user expectations that were not part of the initial specification. Enhancements are relatively cheap compared to features, usually requiring modification to existing code structures, existing tests and existing specs.

Bugs:

Bugs are non-specification meeting behaviors that exist before release. Why before release? Because bugs are registered by whoever is doing QA or acceptance, and are fixed before they reach a production server. Bugs can be extremely contentious when specifications of behavior are unclear.

Why it matters?

Bugs are things we’ll get to before release. They are fixable, and it’s good to be aware of them. They are rarely an all stop, the exception being if QA can not move forward due to a bug. Bugs are best prioritized as the next thing worked on after the current in progress work is completed.

Defect:

You can probably see where this one is going. Defects are bugs that made it into production. These are customer affecting because the customer is the one telling you they’re there.

To some people defect is a dirty word. Does it hurt you or your team’s pride? That’s good, it is a sign that something was allowed to get through.

Why it matters?

If a defect gets logged it means that the impact needs to be immediately assessed and may mean an immediate fix and release. Defects are extremely costly as they cost not only the money to fix, but to get back into what you were doing when your day got interrupted. Defects also cost reputation, as the users are far more likely to remember what went wrong than what goes right.

Conclusion:

Yes, it matters. No they are not all just Change Requests with a priority. If you make a habit of treating a new piece of functionality the way you treat a publicly available defect then your process will run the risk of breaking down to whims. Yes, you can argue, changes are lower priority change requests.

Until someone decides they absolutely need that feature for the software to matter to them.

If your entire software team is focused on a extremely narrow, constantly defined user base, you might be able to execute change requests as a thing unto themselves.

Otherwise, even with internal software, you have to actually weigh the cost and realities of software improvements.