A couple of years ago we did "Bug Bankruptcy" at my old gig. We then instituted a policy: either a bug was worth fixing RIGHT NOW (or reasonably close to it, say after you finish working on your feature) or NEVER. Bugs that were re-reported by users we would move up our mental immediacy list. I like it because it didn't require a fancy software solution - just the group memory. It worked really, really well, and we continue to use it today.
Software Inventory by Joel Spolsky
11–20 of 65 posts
Re: Software Inventory by Joel Spolsky
#12This looks about right for any kind of business, not just software development.
Re: Software Inventory by Joel Spolsky
#13This isn't really a new idea. For anyone interested in 'systems thinking' and associated optimisations, check out the 'Implementing Lean' book: http://www.amazon.co.uk/Implementing-Lean-Software-Developme... Or The Goal for something slightly different: http://www.amazon.co.uk/The-Goal-Process-Ongoing-Improvement... I have to say, there's way more wisdom in the more mature 'lean' world than there is in the trendier '…
Using Joel's definition of inventory and then reading "The Goal" would be a useful thing to do.
IT and software shops often have no clue about what is actually stopping them from shipping product.
Re: Software Inventory by Joel Spolsky
#14This isn't really a new idea. For anyone interested in 'systems thinking' and associated optimisations, check out the 'Implementing Lean' book: http://www.amazon.co.uk/Implementing-Lean-Software-Developme... Or The Goal for something slightly different: http://www.amazon.co.uk/The-Goal-Process-Ongoing-Improvement... I have to say, there's way more wisdom in the more mature 'lean' world than there is in the trendier '…
Using Joel's definition of inventory and then reading "The Goal" would be a useful thing to do. IT and software shops often have no clue about what is actually stopping them from shipping product.
This is why I like lean and systems thinking.
There's so much subtle hidden cost in the system that nobody thinks to look at.
By stepping away from the process that you've fallen or evolved into and looking at the meta level, you can get some massive wins in terms of your productivity, quality etc for little effort.
Re: Software Inventory by Joel Spolsky
#15> A lot of the ideas on the backlog are bad ideas, and you merely wrote them down to avoid hurting the feelings of the people who thought them up. I love how candid he can be sometimes. In my experience, this is true of about 30% of the backlog.
In my experience it doesn't really become clear whether the ideas are good or bad until they've been written down. For this reason I prefer a two-stage backlog, where the first stage is for definition and the second stage is for the ideas from the first stage that you decide you're actually going to do, just not right now.
Yeah, I wouldn't get too hung up on the way Joel phrased it. Clearly ideas have to be considered to some reasonable degree, possibly run past a couple people from different departments, to see if there's anything there.
The trick is just 1) not spending too much time on something after you realize it's anything less than solid 2) not moving them to the official "to do" list just to spare someone's feelings.
Re: Software Inventory by Joel Spolsky
#16He just reinvented Kanban: http://en.wikipedia.org/wiki/Kanban_%28development%29
Re: Software Inventory by Joel Spolsky
#17One easy way to limit the size of the backlog is to let the community itself vote on which bugs and features you should be working on, then add a little editorial selection and take the top (n) to work on. That's what we do at Stack Exchange, anyway:
http://meta.stackoverflow.com/?tab=bugs http://meta.stackoverflow.com/?tab=requests
I find that the community appreciates being involved in these decisions, and often (but not always†) has good ideas of what you should be prioritizing and what issues are true pain points.
† http://www.codinghorror.com/blog/2012/02/listen-to-your-comm...
Re: Software Inventory by Joel Spolsky
#18Joel’s 100% correct about limiting the size of the backlog. It doesn’t matter whether you’re using a kanban system, SRUM, a bug database, Github issues, whatever. The team’s attention is a finite resource, and stuffing items in there wastes it. Limiting the size forces you to throw items out as you go along, and each one of these “We’re never going to do this” decision helps sharpen the design and prevent over-archit…
I've had some personal success with acquiring a bit of a Zen attitude about bugs in the bug database stacking up, and just letting the good stuff float to the top, but this appears to be a very difficult attitude to cultivate, based on the fact almost nobody else seems to be able to do this. I've sometimes managed a middle ground where we create a state in the bug system for "Yes, acknowledged", which basically means nothing but allows those who get freaked out about 3000 bugs being "open" to make the bugs "not open" while not requiring the mental commitment to "close" the bugs. (Don't tell them it means nothing! Of course in practice you are basically closing the bugs as "won't fix", but don't tell your managers that.)
I suppose my metapoint is that there's a lot more psychology going on here than may meet the eye, and there's more than one way to not drown in the bugs of a basically-functional product.
Re: Software Inventory by Joel Spolsky
#19Good read. I think reducing deployment cycles into weeks for large/complex software could only work though if you have a decent set of automated tests.
This is valuable enough to justify writing the tests, isn't it?
No. Cutting your deployment time is equivalent to saving a one-off cost. A comprehensive set of automatic tests is a massive ongoing cost (it's by no means impossible for the tests to cost more than the product), forever. The latter vastly outweighs the former.
There are domains in which you need the tests anyway. If you're in one, you'll probably find your deployment cycle is also constrained by the nature of the domain. If it's not, and if the existence of the tests lets you deploy faster than you otherwise could have, well and good. But it certainly isn't worth investing in the tests just for faster deployment.
Re: Software Inventory by Joel Spolsky
#20Everything 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.