I would call this a task. If I understand you correctly, it is meant to enable a new feature, so it is not a bug fix – otherwise everything should be called a bug.

If the change made by this makes a meaningful difference to end users (independent of the main feature it is meant to support / enable), you may consider calling it a (sub)feature.

All in all, no need to agonize too much on terminology, the main point is to get it done 🙂

Don’t get hung up on what to call it — does it really matter? It’s something that needs to be done, so write a story so that the work gets done. If you are an agile team you have the power to call it whatever you want. Come to a consensus as a team then start worrying about more important things.

I would say that from the moment something doesn’t work to spec, or is simply broken, it is a bug. Anything else is a task/feature/story, in other words: something extra you add to the program.

You could also introduce the concept of a ‘change’: not really fixing something that is broken, not something new you add, but changing how something works (usually as the result of a change in requirements). But that’s three types of ‘todos’, so a change would also be a task.

I’m actually with @pleinolijf and @Péter Török on this: it’s only a bug if the software isn’t working according to the spec. A specification error that wasn’t caught in the design or initial development phase may warrant a spec change and subsequent code changes, but generally speaking, is not a bug.

Generally speaking, a “task” is actually the most generic type of issue in most trackers, and is useful when there is no other fitting type of issue. Anything else (change request, bug, requirement, feature request, gizmo banana, …) is actually a specialization of the “task” issue type. This means that if there is a more appropriate type of issue available, you should think twice about using “task”. Bugs should also be reasonably limited in scope, but of course sometimes it’s hard to tell what the scope of a particular issue will be before having dived into it.

Hence, generalizing, the question really becomes “does the lack of a feature constitute a bug?”. The feature in this case is the ability to set up, in an automated or user-friendly manner, the prerequisites for specific functionality which in turn is laid out in the spec. Since the base functionality is already there and works properly (according to the requirements laid out in the spec) without the change that is being discussed and without requiring workarounds during use, assuming the spec didn’t call for an easy set-up process specifically, I would argue that everything that is currently in the software works the way it is supposed to. Hence, not a “bug”.

What you are talking about is the addition of new functionality (automated set-up of prerequisites), which in general terms has a pretty high bar for being considered a bug in my book.

About the only way I could consider something like this to be a bug is if the specification states that there must be no manual set-up required. Otherwise, it’s a specification omission, which calls for the spec to be updated with the newly discovered desired functionality and for it to be developed along the same lines that the original functionality was (the lack of which probably wasn’t considered a bug).

During the development process, something is only a bug if the programmer has ticked it off the TODO list and thinks that it works. Not if the program doesn’t match the spec yet.

When the specs change (i.e. a new rule “Program should do X”), that doesn’t mean the program suddenly has a new bug (“doesn’t do X yet”).

Your question hits a lot of people very squarely where they live, in a place that can be pretty painful. Bug is not a very precise technical term, but it certainly has a lot of emotional baggage.

Where you work, do people consider features to be planned improvements, and bug fixes to be unplanned improvements? When a developer created code with bugs under the crunch of an all too short schedule, is he or she called back to be accountable for work that might not have been as thorough as needed? As the expert on the code, do people give kudos for a rapid and responsive solution? Do habitual under estimators have consequences after taking credit for features and for being fast, even though finding and fixing their bugs was very frustrating for testers and customers, and very time consuming for developers working on maintenance?

Of course they don’t. The more bugs we have, the less pride of workmanship we have, the less accomplished our team. If you are working on features, you must be trusted and skilled. If on bugs, not so much. Features get a thank you and a party when they are done. Bugs get the silent treatment or a retrospective that discusses how late the release was because we had so many bugs. Maybe where you work the retrospective talks about how the features unfolded into additional unanticipated functional and systems requirements that were not part of the estimate but were resolved with overtime and heroic efforts from team members?

Making a feature is a task. Fixing a bug is a task. What we call bugs are often defects that relate to features we said were done, or missing parts that are due to incomplete understanding of functional or system requirements (or in Agile, user stories or use cases that are incomplete or missing alternative flows).

If our customer visible code is constantly constructed in advance of the underlying support, this is a design or project management problem. We have TDD and unit testing, so ideally, we can be pretty thorough in our testing and pretty selective about exactly when we expose features through the UI to testers, customers, or product management.

Projects often use rapid UI prototyping to show a user interface that has no code behind it. It does not do development any favors if product management believes that 80% of the work is done when that demo is shown, but the project continues to run for a long time. Weigh carefully how far you let your prototypes run ahead of your field ready product.

Agile aims to break the contract mentality and makes collaboration using prototypes more palatable. The relationship and communication between developers and stakeholders needs a high degree of give and take. It helps to methodically manage requirements using a burn down list or other way to limit scope and shorten the time line that is subject to estimation.

Part of our problem is how we track progress. If we have features described by percentage complete, we essentially take credit for something before it is accomplished. Estimates percentage complete are extremely unreliable. If we need to show progress, we should break things down to the level where we can say something that is considered important in our project that stands alone as a cohesive object that provides functionality is completely done. Instead of partially complete milestones, only use fully complete inch-pebbles.

For the work that you describe, if it brings more pride and motivation into the team, I definitely vote for calling it a task and not a bug.

What is the difference between a “bug” and a “task/new feature”?

I define a “bug” as something you have to fix/implement for free (the software provider has to pay the costs).

A “task/new feature” is something the customer has to pay for.

With this definition a customer might see every “issue” as a bug because he will get it fixed for free. The software provider on the other hand wants to get paid for his development.

Your example

Should the sysadmin configure the DNS or hosts file or should our application do it automatically?
An automatic solution is possible. So a decision is made to implement it.

is a classical feature creep.

For a fixed price project the solution for this dilemma is a contract that defines which features are included in the product and which are not.

Every contract-feature that is missing is a bug.