3 ms·

Bugs of logic omission could easily be argued as feature requests. Who is to say that a very poorly written app,done cheaply, whether it intentionally omitted p

Bugs of logic omission could easily be argued as feature requests. Who is to say that a very poorly written app,done cheaply, whether it intentionally omitted proper data validation, or whether adding data validation to resolve downstream errors is a feature request. Another example is the classic, "users would never expect it to work like this" vs "it was designed to work that way (even though it is ass backwards)". Is fixing something to fit user expectations a bug fix, or a feature request? It can really be that the question hinges on an original design spec, which seemingly should not be determining factor (but it is, and who knows whether it was just done badly, or done wrong)

dangus 4y ago
Ultimately all that matters is how many person-hours an organization dedicates to a product that’s considered low priority, finished, deprecated, whatever you want to call it. Debating all the linguistic similes we can use to describe the process is fruitless. Despite that freedom of interpretation, I think your hypotheticals have really clear answers that most software engineers would agree with based on what was originally promised and intended. If a user expects a sorting function to have ascending and descending, but I only originally delivered and promised ascending, later adding descending is a feature/enhancement. It doesn’t matter that the user didn’t like my original implementation, I didn’t promise descending. Conversely, if I add the descending function because I originally intended for that function to be there and wrote some amount of code for that function, but it doesn’t work, that’s a bug fix. I don’t understand the ambiguity, the difference is clear as day to me. In any event, the whole debate revolves around the language of intent. Truthfully, a group of people can make up whatever language they want to describe their approach.
- seadan83 4y ago
  Unsaid, part of my point is the bug vs feature request is a bit of a shell game. Absent the developer & the source code, all that the manager might know is that they are getting support tickets for "this is not working as users expect, we are getting calls into the support center about this." At that point the manager can then decide to do the shell game of "well, we have this JIRA that says it works like that", or, they may choose to say "we are getting bug reports about this, the product does not work as the user expects", and hence it is a bug item. Which then gets into the whole politics of backlog prioritization (feature requests often go to the back, AKA the trash-can, and bug reports maybe get more love..) I think this kinda goes to the point of the article. No matter whether you call it defect remediation, bug fixing, feature work, it's all the same thing - updating an existing software system. I think the point is that the very _vast_ majority of work in software is on existing systems and its almost all is more-or-less the same thing. Which is to say, "maintenance" and "enhancement" are just about the same activity for the software developer. EG: if a feature can be added with a quick 'if' statement, and a bug fix can be fixed the same, are they really different activities? What are the implications relative to the time to understand the system before making that modification?
  - dangus 4y ago
    Essentially my answer to your question in your second to last sentence is “yes” when we zoom out to the business level. It doesn’t matter that the physical activity taking place is the same, because what the activity is for determines where the company puts the expense on the income statement.
    - seadan83 4y ago
      That's the point of the article, no? For a business, they can choose if they want to define a bug as "does not work to spec", or "does not work to user expectation" (I believe we agree there, that this is a distinction without a meaningful difference to development) So, for the developer, the activity is the same. Given most software is existing and not green-field, if you extrapolate this idea out further, it implies that feature and maintenance work have a lot more overlap and are fundamentally the same thing for even larger projects /features than just small bug fixes. It raises the question, at what points and when does feature work and maintenance work become distinct activities?

dangus 4y ago

Ultimately all that matters is how many person-hours an organization dedicates to a product that’s considered low priority, finished, deprecated, whatever you want to call it. Debating all the linguistic similes we can use to describe the process is fruitless. Despite that freedom of interpretation, I think your hypotheticals have really clear answers that most software engineers would agree with based on what was originally promised and intended. If a user expects a sorting function to have ascending and descending, but I only originally delivered and promised ascending, later adding descending is a feature/enhancement. It doesn’t matter that the user didn’t like my original implementation, I didn’t promise descending. Conversely, if I add the descending function because I originally intended for that function to be there and wrote some amount of code for that function, but it doesn’t work, that’s a bug fix. I don’t understand the ambiguity, the difference is clear as day to me. In any event, the whole debate revolves around the language of intent. Truthfully, a group of people can make up whatever language they want to describe their approach.

seadan83 4y ago
Unsaid, part of my point is the bug vs feature request is a bit of a shell game. Absent the developer & the source code, all that the manager might know is that they are getting support tickets for "this is not working as users expect, we are getting calls into the support center about this." At that point the manager can then decide to do the shell game of "well, we have this JIRA that says it works like that", or, they may choose to say "we are getting bug reports about this, the product does not work as the user expects", and hence it is a bug item. Which then gets into the whole politics of backlog prioritization (feature requests often go to the back, AKA the trash-can, and bug reports maybe get more love..) I think this kinda goes to the point of the article. No matter whether you call it defect remediation, bug fixing, feature work, it's all the same thing - updating an existing software system. I think the point is that the very _vast_ majority of work in software is on existing systems and its almost all is more-or-less the same thing. Which is to say, "maintenance" and "enhancement" are just about the same activity for the software developer. EG: if a feature can be added with a quick 'if' statement, and a bug fix can be fixed the same, are they really different activities? What are the implications relative to the time to understand the system before making that modification?
- dangus 4y ago
  Essentially my answer to your question in your second to last sentence is “yes” when we zoom out to the business level. It doesn’t matter that the physical activity taking place is the same, because what the activity is for determines where the company puts the expense on the income statement.
  - seadan83 4y ago
    That's the point of the article, no? For a business, they can choose if they want to define a bug as "does not work to spec", or "does not work to user expectation" (I believe we agree there, that this is a distinction without a meaningful difference to development) So, for the developer, the activity is the same. Given most software is existing and not green-field, if you extrapolate this idea out further, it implies that feature and maintenance work have a lot more overlap and are fundamentally the same thing for even larger projects /features than just small bug fixes. It raises the question, at what points and when does feature work and maintenance work become distinct activities?