3 ms·

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

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

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?