Reminds me of the story in Chuang Tzu about an old man who loses his memory. Various cures are tried to no avail. Eventually a learned doctor is brought in who after much effort succeeds in curing the man. In a flash, all his memories return. Immediately he proceeds to beat the doctor with a stick, saying "How dare you? I was doing great and now you've ruined everything!"
Software Inventory by Joel Spolsky
61–65 of 65 posts
Re: Software Inventory by Joel Spolsky
#62Earlier quoted context omitted.
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 s…
"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 o…
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.
Re: Software Inventory by Joel Spolsky
#63Joel is saying what the lean-manufacturing inspired people have been saying for years. I think it is a mis-mapped metaphor.
When you diligently draw the parallels between manufacturing and software development you end up with the notion that the whole of your code base is inventory:
http://michaelfeathers.typepad.com/michael_feathers_blog/201...
Re: Software Inventory by Joel Spolsky
#64Earlier quoted context omitted.
"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 o…
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.
This is about open bugs. Closed bugs are easy to ignore.
Ubuntu has 98614 open 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).
Re: Software Inventory by Joel Spolsky
#65Earlier quoted context omitted.
"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 o…
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 reporte…
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!