[e_i_pi]

I'm wondering if anyone has any solid explanation of why there are the terms "Enhancement" and "Feature Request"? Surely they refer to the same concept...

When I first thought about this, a Feature Request evoked the idea of something new and not yet in the application. Adversely, an Enhancement suggests that the feature exists but needs to be made better. But when it boils down to it, isn't an Enhancement simply a new Feature? For example, let's say we have a form with a field for date of birth. Adding an on-click widget to bring up a better interface than simply text, to me, sounds like an enhancement. But if you look at it, it really is a feature, as you're adding new functionality.

The reason I ask this is that I'm implementing a bug tracking system (third party) at my new workplace, which doesn't have one. Up until now, they've used Sharepoint lists, which baffles me as we're one of the leading Universities in the world, and our Faculty has one of the most progressive IT arms in the organisation. Anyhow, I'm configuring the application, and the default issue types are "Bug", "Enhancement", and "Feature Request". I'm thinking of ditching Feature Request, as it seems moot to me.

Thoughts, feedback?

This post has been edited by e_i_pi: 26 January 2016 - 10:02 PM

[jon.kiparsky]

It really depends what you want to keep track of, but I tend to agree with you - I don't see what this distinction would gain you, and I can picture the bickering over whether this ticket is a Feature Request or an Enhancement. Make it simple: distinguish between fixing stuff that's broken and adding new stuff, and be done with it.

[jon.kiparsky]

Quote

Up until now, they've used Sharepoint lists, which baffles me as we're one of the leading Universities in the world, and our Faculty has one of the most progressive IT arms in the organisation.

I wish I could say I was surprised by this, but it's all too common. An organization starts out thinking, well, we don't really need all that stuff, we can get away with writing them down on this old shopping bag, and then just throw the bag away when we've finished all the items on it. And then after a year or two they all get used to the shopping bag and it's just the way we do stuff around here, and maybe you get some junior guys who started off with the shopping bag and they're pretty good at it - they can really, um, write issues on the shopping bag, or whatever. And then you've got a whole shelf of old shopping bags, because it turns out you can't really throw them away, and there's a guy who mostly just keeps track of that, and of course he's really into that system because that's mostly what he does, and it'd be a lot of work to change over to this fancy new system, and really the shopping bag doesn't that THAT long, so maybe we'll upgrade to a new system when we have time - but for now, we have three shopping bags full of issues to work on, so obviously there's no time to deal with that.

And that's how that happens.

[e_i_pi]

Yeah, I'm all too familiar with this approach as well. I tend to run a pretty tight ship with my code, tools, and general work space. I've inherited, let's say, an interesting setup that is lacking in certain tools, or has tools with all the bells and whistles, in the form of third-party library Frankenstein code madness. Thankfully the overall setup isn't too far down the rabbit hole to steer back on the right path, but I'm going to have to make some tough decisions between whether I rewrite certain applications or just keep them on life support until end of life. The problem with that is, an EOL of "next year" really means "sometime after next year", which roughly translates to "never".

jon.kiparsky, on 27 January 2016 - 03:21 PM, said:

It really depends what you want to keep track of, but I tend to agree with you - I don't see what this distinction would gain you, and I can picture the bickering over whether this ticket is a Feature Request or an Enhancement. Make it simple: distinguish between fixing stuff that's broken and adding new stuff, and be done with it.

Yep, I think simplification is the way to go. My first impressions of starting this job were [A] there's a lot of quick fixes been applied and [B] there's a lot of room for consolidation / reducing technical debt. I'll keep an eye on this topic, but the "it's broken" vs "it's not there" distinction makes sense to me.

This post has been edited by e_i_pi: 26 January 2016 - 10:37 PM

[Skydiver]

So if somebody says "when I click on this button, it takes 2 minutes to get a result. Please make it faster." Is it an enhancement, a performance bug, or a feature request?

[TechnoBear]

My original thinking reading through your post was that enhancements are bugs that people don't want to call bugs.

I used to have a boss that refused to admit anything was wrong with the system even when asking us to fix something so in the 2 years I was there I don't think I ever heard the word bug.

[andrewsw]

A bug is a feature waiting to be discovered.

[TechnoBear]

Quote

A bug is a feature waiting to be discovered.

pretty sure i have this on a T-Shirt somewhere =P

[jon.kiparsky]

Skydiver, on 27 January 2016 - 07:59 AM, said:

So if somebody says "when I click on this button, it takes 2 minutes to get a result. Please make it faster." Is it an enhancement, a performance bug, or a feature request?

Depends whether a reasonable loading time was part of the "definition of done" for the original feature.

[Skydiver]

There was no perf requirement from the client's original requirments, and the issue only turned up two years later when they had accumulated two years worth of data (and the bubble sort implemented within the program started showing why you don't use bubble sort). The client was supposed to only keep 6 months of data at any given time.

[astonecipher]

Our breakdown is bug, improvement, new feature. It works well, but the Lead Project manager also goes thru and prioritizes them and realigns them if he doesn't feel they are in the right category.

[jon.kiparsky]

What happens if the new feature improves the product?

[TechnoBear]

Quote

What happens if the new feature improves the product?

In my experience they just add bugs.

[Skydiver]

Also, there is a interesting financial dimension to the classification. An internal client wants a "enhancement/new feature" but not pay for it. They tag it as a "bug" to be charged against our "lights on" budget, instead of their "development" budget.

[e_i_pi]

Skydiver, on 27 January 2016 - 10:59 PM, said:

So if somebody says "when I click on this button, it takes 2 minutes to get a result. Please make it faster." Is it an enhancement, a performance bug, or a feature request?

I make the distinction between bugs and features/enhancements as:

• Bug: An error is occurring that is preventing work from being done or is not executing as intended (e.g. - writing the wrong values to the DB)
  
• Feature/Enhancement: A new process, or any improvement to an existing process

So in the case you gave above, I would call it an enhancement, and not get too semantic about it. I do see your point though, maybe if I explain my general approach to development, it will become clearer.
I believe there are 4 major components to application development, with the priority being top to bottom, but the target (read: ideal) workload being bottom to top:

• Bug Fixes (generally reported by the end user, though also picked up in logs)
  
• Maintenance (includes setting up source control, monitoring systems, identifying optimisations, documentation, general support, etc.)
  
• Enhancements (generally reported by the end user, but can come form IT itself)
  
• Innovation (generally comes from IT by engaging with the business to identify chokepoints or iterative processes)

Bug Fixes should always be solved first, unless they are trivial or have feasible workarounds. Maintenance can be routine (e.g. scheduled task, user training) or can precipitate an Enhancement to automate/streamline/improve the task. Enhancements can precipitate Bug Fixes or Maintenance, but ideally create neither. Innovation generally creates multiple Enhancements.

So really, there are two major components when it comes to actual development that you need to track - Bug Fixes, and Enhancements. Everything else flows towards these. There's no need to over-analyse this, I'm sure there are edge cases and things that don't fall into this easily, but I think it covers 95+% of development work.

TechnoBear, on 27 January 2016 - 11:36 PM, said:

My original thinking reading through your post was that enhancements are bugs that people don't want to call bugs.I used to have a boss that refused to admit anything was wrong with the system even when asking us to fix something so in the 2 years I was there I don't think I ever heard the word bug.

Before I posted here, I read the following article on Coding Horror, which I think nicely investigates your argument.

Skydiver, on 28 January 2016 - 03:02 AM, said:

Also, there is a interesting financial dimension to the classification. An internal client wants a "enhancement/new feature" but not pay for it. They tag it as a "bug" to be charged against our "lights on" budget, instead of their "development" budget.

Thankfully I'm in a position where we don't have a budget in the sense of project work vs support work. All work is just done by the team - the only expenses are hardware and third party products (e.g. Office licencing, Oracle licencing, etc.). My last workplace had defects, gaps, known issues, and enhancements as the fallout from project development. Project Managers would spend weeks arguing with business users and vendors over the classification of issues in order to massage the budget into the black - I found this reprehensible, as it completely ignored the ultimate goal (positive end user experience), as well as wasted money on managers, who are just slightly above lizard people on my scale of repugnant beings.

This post has been edited by e_i_pi: 27 January 2016 - 03:40 PM