3 ms·

Everything that Joel says is true, but keep in mind: having inventory or backlog has a cost, but everything that clears it also has a cost. Inventory is always

by lmkg 14y ago

Everything that Joel says is true, but keep in mind: having inventory or backlog has a cost, but everything that clears it also has a cost. Inventory is always bad, but sometimes it's less-bad than the alternatives. Anecdata: My company has a client with a large budget and a large appetite for change on his website. The project manager intentionally chosen to throttle back the rate of change and build up a backlog. The intention is the rate of work is about enough to employ 4 people full-time, and we'd rather have that be consistent rather than just an average. Were he to clear the backlog as it came in, the flow of work would be very uneven, and that would necessitate all sorts of other overhead costs. During boomtimes, onboarding new people to the project; during busttimes, finding other work for the 4 current people; during the transitions between the two, juggling obligations from 2-3 projects as people get transfered from one project to another. TL;DR project management is hard. Reducing inventory is a Good Thing and you should do it, but it has a cost, so don't be cargo-cultish about it.

SoftwareMaven 14y ago
To be fair, he said to do exactly what you said: cut the backlog off at X weeks. For something new to come in, something else has to go. It was the bug db he recommended clearing out, which I kind of agree with. Little is more disheartening to a developer than seeing a project with 3000 bugs. You can't help think your project sucks, so why bother (or you learn to completely ignore the bug db). Regardless, your last statement of "don't be cargo-cultish" always applies. Understand the tradeoffs for your organization. Even Joel just called them "suggestions" not "here's how you do it".
- keithpeter 14y ago
  "Little is more disheartening to a developer than seeing a project with 3000 bugs." Try 100,000 I was slightly active as a tester for Ubuntu 12.04 (a long term release so things that did not make the UI and package freeze would be there for years) I noticed a lot of minor bugs being labelled 'won't fix', and I noticed a lot of 'down chain' bugs happening because of kernel/X server &c which automatically got sorted once the fixed packages made it in. The whole thing was most educational to me (as an end user) and the result is rather nice.
  - SoftwareMaven 14y ago
    That would be an interesting experiment. 100,000 bugs, the vast majority of which you have no control over; 3,000 bugs, the vast majority of which you have control over but aren't going to do anything about; or 100 bugs that you know you are going to quash. I can see how the first two could be quite painful for developers, but they are also helpful for support reasons. "Yes, that annoying menu things has been reported and we just aren't going to get around to fixing it," seems better than a bug black hole that continually swallows everything customers/support tells it.
    - keithpeter 14y ago
      launchpad does that triage, they have people processing stuff most days. It was educational watching how the various freezes along the time line funnelled the bugs that would get fixed. This is an extreme example, a whole operating system with non-trivial packaging. Your phone app should be easier! pyroom have a suggestions tracker... the thing is meant to be minimal!
  - infinii 14y ago
    The biggest reason against removing such "won't fix" bugs from a bug db is that it's kept for historical reasons. If a user reports it again, a search of the bug db will indicate that an investigation has been performed and the bug isn't worthy of being fixed. If it'd been deleted, support would waste time duplicating the investigation again.
    - warp 14y ago
      This is about open bugs. Closed bugs are easy to ignore. Ubuntu has 98614 open bugs: https://launchpad.net/ubuntu/+bugs https://launchpad.net/ubuntu/+bugs (Though I expect that would also include feature requests / wishlist items, so the actual bug count would be slightly lower).
barista 14y ago
>> Reducing inventory is a Good Thing and you should do it, This to me seemed like one of the most important points of the article but I am not sure how this works for a software factory. In the bread factory business what if you had an endless supply of flour and sesame seeds available to you that costs next to nothing to buy and store? Now in case of software the cost of "purchasing" and maintaining the raw material (feature requests and bugs) is much much lower than what it is for a bread factory.

by lmkg 14y ago

SoftwareMaven 14y ago

To be fair, he said to do exactly what you said: cut the backlog off at X weeks. For something new to come in, something else has to go. It was the bug db he recommended clearing out, which I kind of agree with. Little is more disheartening to a developer than seeing a project with 3000 bugs. You can't help think your project sucks, so why bother (or you learn to completely ignore the bug db). Regardless, your last statement of "don't be cargo-cultish" always applies. Understand the tradeoffs for your organization. Even Joel just called them "suggestions" not "here's how you do it".

keithpeter 14y ago
"Little is more disheartening to a developer than seeing a project with 3000 bugs." Try 100,000 I was slightly active as a tester for Ubuntu 12.04 (a long term release so things that did not make the UI and package freeze would be there for years) I noticed a lot of minor bugs being labelled 'won't fix', and I noticed a lot of 'down chain' bugs happening because of kernel/X server &c which automatically got sorted once the fixed packages made it in. The whole thing was most educational to me (as an end user) and the result is rather nice.
- SoftwareMaven 14y ago
  That would be an interesting experiment. 100,000 bugs, the vast majority of which you have no control over; 3,000 bugs, the vast majority of which you have control over but aren't going to do anything about; or 100 bugs that you know you are going to quash. I can see how the first two could be quite painful for developers, but they are also helpful for support reasons. "Yes, that annoying menu things has been reported and we just aren't going to get around to fixing it," seems better than a bug black hole that continually swallows everything customers/support tells it.
  - keithpeter 14y ago
    launchpad does that triage, they have people processing stuff most days. It was educational watching how the various freezes along the time line funnelled the bugs that would get fixed. This is an extreme example, a whole operating system with non-trivial packaging. Your phone app should be easier! pyroom have a suggestions tracker... the thing is meant to be minimal!
- infinii 14y ago
  The biggest reason against removing such "won't fix" bugs from a bug db is that it's kept for historical reasons. If a user reports it again, a search of the bug db will indicate that an investigation has been performed and the bug isn't worthy of being fixed. If it'd been deleted, support would waste time duplicating the investigation again.
  - warp 14y ago
    This is about open bugs. Closed bugs are easy to ignore. Ubuntu has 98614 open bugs: https://launchpad.net/ubuntu/+bugs https://launchpad.net/ubuntu/+bugs (Though I expect that would also include feature requests / wishlist items, so the actual bug count would be slightly lower).

barista 14y ago

>> Reducing inventory is a Good Thing and you should do it, This to me seemed like one of the most important points of the article but I am not sure how this works for a software factory. In the bread factory business what if you had an endless supply of flour and sesame seeds available to you that costs next to nothing to buy and store? Now in case of software the cost of "purchasing" and maintaining the raw material (feature requests and bugs) is much much lower than what it is for a bread factory.