5 ms·

Looking forward to the suggested answer. Guess I would delete all issues except for the most critical bugs and any remaining critical mvp features, and then I

by pajtai 11y ago

Looking forward to the suggested answer. Guess I would delete all issues except for the most critical bugs and any remaining critical mvp features, and then I would say that from that point on you can't add any feature requests without completing something - that is you can only add a feature ticket after completing a bug or other feature ticket.... for sprints I'd say 3 to 1 bug to feature ratio and no more than 1 feature at a time in progress / in sprint at any time. Then if normalcy returns I'd ease up. I'd also make sure there's one lead dev in charge long term on the project instead of just having whoever has "some time to do it." Not sure if this is ideal, which is why I'm looking forward to your answer.

sandal 11y ago
This is pretty close to what I ended up doing. I've repeated this process elsewhere too, both for other companies and on my own projects... though the example shown was among the most severe. In the essay, I'll try to be a bit more precise though, because in practice you might have a hard time with getting buy in on "Delete the issues" and an easier time with what I actually did on this project: "create a priority queue that only the product owner and CEO can touch, treat that as the new official backlog until the crisis is resolved, put a bunch of rules on what gets in there and how much it can hold, then track progress actively" More details will be shared in a couple days, can't wait to hear responses. :-) If you want the followup essay in your inbox, sign up here: https://tinyletter.com/programming-beyond-practices https://tinyletter.com/programming-beyond-practices
- Torn 11y ago
  Right - the important thing is recognizing that their development processes (or lack of them) has lead to this situation. Treating the symptoms is no guarantee they won't end up in the same situation in the future.
mikekchar 11y ago
I will suggest that bugs and features are not as different as most people think. In both cases you are adding functionality that is not present in the current implementation. The difference is that in a feature, nobody expects the functionality to exist. In a bug, people expected the functionality to exist (either because it existed in a previous version, or because it was thought to have been implemented and it turns out that it wasn't). People react badly to bugs because they feel it is a result of a mistake -- developers broke something they shouldn't, or they didn't do a good job in a previous implementation. The feeling is that a bug has the highest priority, but in reality, there is no such connection from "previous mistake" to "important now". If the only difference between a bug and a feature is that a feature is not expected to already be present, as soon as you discover a bug it becomes a feature request -- we now know that functionality is not present. It should be prioritised in exactly the same way. The key to solving the problem posed by the article is fairly clear. Get a list of all the things the you are not going to implement. Remove them from the list. Done. Whether these are bugs or features is irrelevant.
- joepvd 11y ago
  I agree with you. One notable difference between a bug and a feature is who will pay for development/testing/support time.
  - zer00eyz 11y ago
    This is huge. A capital expense can be amortized (feature dev falls firmly in this category) where a defect (typically) ends up in operating expenses. Many devs are blissfully unaware of the influence accounting (the other nerds) has on an organization. Lots of PM groups are driven almost exclusively by "new features" and poor estimates on their value. I have been hard pressed to find a PM that will do a one week project that adds 100k to the bottom line over a 10 week one that adds 500k even though the former has a better ROI.
- sandal 11y ago
  Good insight. I didn't split the categories for the report (nor did I distinguish in the essay) for pretty much exactly this reason.
- tajen 11y ago
  Another difference is that we can evaluate how long a feature will take. The biggest category of bugs can't be evaluated because their origin is unknown, and by the time the developer has found the problem, they might as well solve it than push them in a planning.

by pajtai 11y ago

sandal 11y ago

This is pretty close to what I ended up doing. I've repeated this process elsewhere too, both for other companies and on my own projects... though the example shown was among the most severe. In the essay, I'll try to be a bit more precise though, because in practice you might have a hard time with getting buy in on "Delete the issues" and an easier time with what I actually did on this project: "create a priority queue that only the product owner and CEO can touch, treat that as the new official backlog until the crisis is resolved, put a bunch of rules on what gets in there and how much it can hold, then track progress actively" More details will be shared in a couple days, can't wait to hear responses. :-) If you want the followup essay in your inbox, sign up here: https://tinyletter.com/programming-beyond-practices https://tinyletter.com/programming-beyond-practices

Torn 11y ago
Right - the important thing is recognizing that their development processes (or lack of them) has lead to this situation. Treating the symptoms is no guarantee they won't end up in the same situation in the future.

mikekchar 11y ago

I will suggest that bugs and features are not as different as most people think. In both cases you are adding functionality that is not present in the current implementation. The difference is that in a feature, nobody expects the functionality to exist. In a bug, people expected the functionality to exist (either because it existed in a previous version, or because it was thought to have been implemented and it turns out that it wasn't). People react badly to bugs because they feel it is a result of a mistake -- developers broke something they shouldn't, or they didn't do a good job in a previous implementation. The feeling is that a bug has the highest priority, but in reality, there is no such connection from "previous mistake" to "important now". If the only difference between a bug and a feature is that a feature is not expected to already be present, as soon as you discover a bug it becomes a feature request -- we now know that functionality is not present. It should be prioritised in exactly the same way. The key to solving the problem posed by the article is fairly clear. Get a list of all the things the you are not going to implement. Remove them from the list. Done. Whether these are bugs or features is irrelevant.

joepvd 11y ago
I agree with you. One notable difference between a bug and a feature is who will pay for development/testing/support time.
- zer00eyz 11y ago
  This is huge. A capital expense can be amortized (feature dev falls firmly in this category) where a defect (typically) ends up in operating expenses. Many devs are blissfully unaware of the influence accounting (the other nerds) has on an organization. Lots of PM groups are driven almost exclusively by "new features" and poor estimates on their value. I have been hard pressed to find a PM that will do a one week project that adds 100k to the bottom line over a 10 week one that adds 500k even though the former has a better ROI.
sandal 11y ago
Good insight. I didn't split the categories for the report (nor did I distinguish in the essay) for pretty much exactly this reason.
tajen 11y ago
Another difference is that we can evaluate how long a feature will take. The biggest category of bugs can't be evaluated because their origin is unknown, and by the time the developer has found the problem, they might as well solve it than push them in a planning.