Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Inventory by Joel Spolsky

joelonsoftware.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Software Inventory by Joel Spolsky

#31

Post by mcherm »

grecy wrote: post #29

> That means on the average day you have 150 metric tons of wheat flour in stock. At today’s prices, you’ve tied up $73,000. Forever. What's so bad about having that money tied up in inventory? Once it's in there, you can just forget about it, and it has no impact. If you reduce your inventory and "free up that money", you're just going to spend it on something else, and then be on an endless quest to forever reduce…

From an economic sense, the problem of the money tied up in inventory is precisely the interest on $73,000. (Interest rate you pay on loans if you have any loans, interest you'd get from a bank account if you don't have loans.) So around a dollar a day at today's interest rates. (It gets worse if you figure in the small probability of spoilage or damage that is uninsured.)

Re: Software Inventory by Joel Spolsky

#32

Post by grecy »

raganwald wrote: post #21
codinghorror wrote: post #17

One 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 (b…

True, although software can never be 100% user/customer/community driven. Something Henry Ford something something “faster horses.” Or within my lifetime, if we had take a survey in 1983, how many personal computer users would have voted for “mouse and bitmapped screen” as their top priority?

Steve Jobs has a famous quote about hating focus groups.

"You can't ask people what they want because they haven't seen it yet."

(or something along those lines)

Re: Software Inventory by Joel Spolsky

#33

Post by dllthomas »

raganwald wrote: post #21
codinghorror wrote: post #17

One 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 (b…

True, although software can never be 100% user/customer/community driven. Something Henry Ford something something “faster horses.” Or within my lifetime, if we had take a survey in 1983, how many personal computer users would have voted for “mouse and bitmapped screen” as their top priority?

> [H]ow many personal computer users would have voted for “mouse and bitmapped screen” as their top priority?

I still wouldn't...

Re: Software Inventory by Joel Spolsky

#35

Post by mcherm »

Rather than emptying out the bug database, I prefer keeping two different "levels" of bug reports. There's the "current" bug database, which you try to keep small and which you clean regularly and work from. And there's the "deep backlog" which winds up being pretty much a collection of random junk. The "deep backlog" is rarely looked at (so it doesn't become a waste of time and attention), but you also don't throw it out wholesale, because it costs almost nothing to keep around. Occasionally you'll try to data-mine the deep backlog. You may also go through every year or two and do a mass cleanup; or you may allow a sort of "voting" process to identify items from the deep backlog that are worth considering for the "real" bug list.

Re: Software Inventory by Joel Spolsky

#37

Post by gojomo »

jerf wrote: post #18
raganwald wrote: post #2

Joel’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…

Indeed, I prefer this approach to Joel's. Whether a giant bug list actually wastes any attention is a matter of attitude, terminology, and interface.

If the moldy oldy bugs collect mostly out of view, but can be found when needed – for example when a similar bug is reported again, or an overlapping feature is being added – then this 'long tail' of bugs can be an asset rather than an inventory cost.

In fact, I would suggest any mental model that relies too much on the 'physical inventory' analogy can't possibly be making optimal use of the possibilities of digital technology. Bits are nearly free, interface is iteratively-malleable, and improving search offers instant only-when-needed access to arbitrarily large backlogs and historic records.

I understand that some meticulous personality types can find this approach disturbing – and these are personality types that are especially good software developers in many dimensions. This tension should be resolved with terminology and interface: let each team member see only the backlog that helps them allocate their attention.

There are parallels to the deletionist-vs-inclusionist split in wiki/reference communities. Joel is a bug-deletionist. I am a bug-inclusionist.

Re: Software Inventory by Joel Spolsky

#38

Post by jdlshore »

I can't help but feel a bit irritated about this post of Joel's. It's rehashing some very old Agile ideas as if they were somehow fresh and new, all in support of yet another project management tool. (As if we need another one of those.)

Anyway, I'm glad he's helping to spread these ideas. I just wish Joel had been a bit more forthcoming about the rich history he's drawing from, and would give people the opportunity to read up on it in more detail.

(Relatedly, if you're interested in how these ideas apply to multi-team development, I did a talk at Philly ETE earlier this year about applying the Lean and Kanban to large-scale Agile development. Here's the video: http://vimeo.com/43956744 )

Re: Software Inventory by Joel Spolsky

#39

Post by MattRogish »

jpadkins wrote: post #22
MattRogish wrote: post #11

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 c…

You didn't actually lean out the process, you just pushed more work on to a different group of people. Did people pay for this software? I can't imagine buying software that makes me find/submit bug reports and then on top of that re-submit them to actually get them fixed....

Not every bug is worth fixing. But, I'd probably guess that 9x% of user-reported bugs are of the "this needs immediate fixing" variety. A lot of other bugs, mostly entered by QA and other folks in the company, fall into the "WONTFIX" bucket.

Re: Software Inventory by Joel Spolsky

#40

Post by kinleyd »

gecko wrote: post #36
kinleyd wrote: post #30

Going off-topic here, but that was a cool dog. Looks like a huskie. :)

His name is Taco. He's a very gentle dog, although (as my fiancée discovered) one who moves like a bullet if you happen to be holding a bagel and lox and let your guard down.

Heh, thanks. Nice to know that Taco can be as fast as a bullet when the opportunity presents itself. :)
Post reply on HN