5 ms·

Please just declare "Backlog Bankruptcy". Start a new project in JIRA or whatever. Get rid of the encumbrances of the history of all the accumulated bugs (in

by win_ini 11y ago

Please just declare "Backlog Bankruptcy". Start a new project in JIRA or whatever. Get rid of the encumbrances of the history of all the accumulated bugs (including some that list mundane "misspellings" of "neighbour"). You mentioned triage. Triage takes place at different levels. Clear the table and focus on the items that will really move your business and the project. The issues that were previously removed - will re-surface if they are relevant to your current customers. Before you do that, ask - "what IS most important for our business in the next 3/6 months that we can impact with our limited resources" However, I suspect that if your chart looks that nasty, you'd have a hard time convincing people to do that. In the end, parts of your team could probably now be put to work since they aren't just managing stories in JIRA that will never be completed anymore. Can't wait for the followup post.

sandal 11y ago
Well, you're pretty close to having written it yourself. :-) The benefit I had in this particular project is that I was an outside consultant with full access to everyone and everything in the organization AND the trust of some of the leadership there as well as a couple of the developers. That's a pretty big benefit and not typical. Still, I think it's important to talk about what did work (I waited years before publishing this essay, and repeated it a couple times elsewhere), because even if you don't have the leverage, knowing how to make a strong case is half the battle. Will post the followup within the next day or two!
true_religion 11y ago
I'm in the middle of this right now, and I can tell you triage is really hard. As we rip through the scar tissue of old badly done bug fixes, we find new undocumented bugs. So while we might fix 10 bugs a week, we add 3 a day... not including newly formed UI suggestions.
shalmanese 11y ago
Every stochastic inbox/outbox patterned software (todo lists, email, issue tracker, rss reader) follows this same pattern where there are only two stable outcomes: Inbox Zero or Bankrupt. Because the stream of incoming is random and uncontrolled by you, unless the time you devote to clearing your inbox vastly exceeds the incoming stream, all queues converge upon bankruptcy inevitably. Given this, it's worthwhile thinking about bankrupt only software. Twitter is a great example of bankrupt only thinking. One of the crucial things Twitter did that differentiated itself from RSS is it never put an unread counter anywhere. You expect to go into Twitter, reading only some small percentage of your stream. You assume that if a link is important enough, enough people will post it that you'll eventually see it. But also, if you don't, it's no big deal. It's interesting thinking about what a bankrupt only issue tracker would look like. Perhaps a version could be that when an engineer logs in, he only sees one issue at a time and has the choice of "I want to work on this issue", "I know someone who should work on this issue" and "I don't want to work on this issue". You can click around a couple of times until you find an issue to work on and then get straight to work. Crucially, there's no way to see the global list of issues and duplicates are encouraged, not discouraged. If an issue is duplicated many times, it means more of a chance that someone will hit upon it stochastically. I have no idea if this will work, probably not. But I think people need to start thinking outside of the todo list paradigm for issue tracking to make any meaningful progress forward.
- bojo 11y ago
  How would duplicates be tracked if you can't see the global list to link them together? Sounds like you'd end up with a lot of potential wasted effort on "interesting" issues being worked on simultaneously.
  - shalmanese 11y ago
    I don't know. I haven't thought closely enough about the issue. But what I do know is that often, the difficulty of moving towards a new paradigm is that constraints which are considered essential under an old paradigm turn out to be not big deals under the new one. My term "bankrupt only software" takes inspiration from "crash only software" which also faced this same shift in mindset. Maybe there are additional constraints to be added to make dupes not a big deal (each issue can only be a day's worth of work max). Maybe it will turn out that dupes aren't a big deal anyway and that the increase in productivity offset the occasional dupe. The thought experiment was basically RSS Reader:Twitter::Issue Tracker:???

by win_ini 11y ago

sandal 11y ago

Well, you're pretty close to having written it yourself. :-) The benefit I had in this particular project is that I was an outside consultant with full access to everyone and everything in the organization AND the trust of some of the leadership there as well as a couple of the developers. That's a pretty big benefit and not typical. Still, I think it's important to talk about what did work (I waited years before publishing this essay, and repeated it a couple times elsewhere), because even if you don't have the leverage, knowing how to make a strong case is half the battle. Will post the followup within the next day or two!

true_religion 11y ago

I'm in the middle of this right now, and I can tell you triage is really hard. As we rip through the scar tissue of old badly done bug fixes, we find new undocumented bugs. So while we might fix 10 bugs a week, we add 3 a day... not including newly formed UI suggestions.

shalmanese 11y ago

Every stochastic inbox/outbox patterned software (todo lists, email, issue tracker, rss reader) follows this same pattern where there are only two stable outcomes: Inbox Zero or Bankrupt. Because the stream of incoming is random and uncontrolled by you, unless the time you devote to clearing your inbox vastly exceeds the incoming stream, all queues converge upon bankruptcy inevitably. Given this, it's worthwhile thinking about bankrupt only software. Twitter is a great example of bankrupt only thinking. One of the crucial things Twitter did that differentiated itself from RSS is it never put an unread counter anywhere. You expect to go into Twitter, reading only some small percentage of your stream. You assume that if a link is important enough, enough people will post it that you'll eventually see it. But also, if you don't, it's no big deal. It's interesting thinking about what a bankrupt only issue tracker would look like. Perhaps a version could be that when an engineer logs in, he only sees one issue at a time and has the choice of "I want to work on this issue", "I know someone who should work on this issue" and "I don't want to work on this issue". You can click around a couple of times until you find an issue to work on and then get straight to work. Crucially, there's no way to see the global list of issues and duplicates are encouraged, not discouraged. If an issue is duplicated many times, it means more of a chance that someone will hit upon it stochastically. I have no idea if this will work, probably not. But I think people need to start thinking outside of the todo list paradigm for issue tracking to make any meaningful progress forward.

bojo 11y ago
How would duplicates be tracked if you can't see the global list to link them together? Sounds like you'd end up with a lot of potential wasted effort on "interesting" issues being worked on simultaneously.
- shalmanese 11y ago
  I don't know. I haven't thought closely enough about the issue. But what I do know is that often, the difficulty of moving towards a new paradigm is that constraints which are considered essential under an old paradigm turn out to be not big deals under the new one. My term "bankrupt only software" takes inspiration from "crash only software" which also faced this same shift in mindset. Maybe there are additional constraints to be added to make dupes not a big deal (each issue can only be a day's worth of work max). Maybe it will turn out that dupes aren't a big deal anyway and that the increase in productivity offset the occasional dupe. The thought experiment was basically RSS Reader:Twitter::Issue Tracker:???