
Software Inventory by Joel Spolsky - moobirubi
http://www.joelonsoftware.com/items/2012/07/09.html
======
lmkg
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
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
"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
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
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!

------
codinghorror
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 (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...](http://www.codinghorror.com/blog/2012/02/listen-to-your-community-
but-dont-let-them-tell-you-what-to-do.html)

~~~
raganwald
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?

~~~
codinghorror
I didn't say 100%, did I? Anyone pushing for 100% of anything is basically
crazy.

Also, as for "faster horses", per this article "We have no evidence that Ford
ever said those words."

[http://blogs.hbr.org/cs/2011/08/henry_ford_never_said_the_fa...](http://blogs.hbr.org/cs/2011/08/henry_ford_never_said_the_fast.html)

------
raganwald
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-architecture.

~~~
jerf
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.

~~~
gojomo
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.

~~~
mechanical_fish
_Bits are nearly free, interface is iteratively-malleable, and improving
search offers instant only-when-needed access to arbitrarily large backlogs…_

I am very suspicious of this argument, although I freely admit that my
instincts are colored by my old company's use of Atlassian Jira. I was
generally okay with Jira, at times when the backlog was under control, but if
there's an issue tracker that can manage several thousand active entries
without reducing you to tears, Jira is not it.

Bits are nearly free, but human attention is not. Human attention is even
_smaller_ than a physical filing system.

Issue-tracker interfaces may in theory be "infinitely malleable" but that's a
yak-shaving exercise waiting to happen. Every minute a team spends redesigning
or reconfiguring the issue tracker is a minute they aren't spending working on
the product. That's Spolsky's point.

Search? When there's _one_ issue in the backlog about the color of the toolbar
then search will work great. But then the toolbar acquires a "color" palette.
And then two years go by, during which people keep bikeshedding aspects of the
toolbar. And then one day you'll search for "toolbar + color" and up will come
fifty entries. Which you will probably have to read.

If you're a talented search jockey you can probably construct a better query
to whittle down that SERP page, assuming your issue tracker has a Google-
quality search backend, which it probably does not. But constructing fancy
searches takes time and thought. And there's a garbage-in-garbage-out problem
with search: If your issues aren't written with a sufficient level of detail,
precision, care, and choice of terminology (and somehow they never are), your
search won't distinguish them well. Reporting bugs well takes a lot of time
and care. Writing carefully-described issue descriptions with a standard
terminology takes time, even if you're a trained library scientist. And,
again: All that time spent refining searches, scanning SERP pages, and writing
well-crafted issue descriptions for better searchability is time you're not
spending on the product. You can't ship the prose in your issue tracker.

------
benjaminwootton
This 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...](http://www.amazon.co.uk/Implementing-Lean-Software-Development-
Addison-Wesley/dp/0321437381/ref=sr_1_1?ie=UTF8&qid=1341845698&sr=8-1)

Or The Goal for something slightly different:

[http://www.amazon.co.uk/The-Goal-Process-Ongoing-
Improvement...](http://www.amazon.co.uk/The-Goal-Process-Ongoing-
Improvement/dp/0566086654/ref=sr_1_1?s=books&ie=UTF8&qid=1341845732&sr=1-1)

I have to say, there's way more wisdom in the more mature 'lean' world than
there is in the trendier 'agile'.

~~~
Spooky23
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.

~~~
benjaminwootton
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.

------
MattRogish
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.

~~~
jpadkins
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....

~~~
derefr
> 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....

This is what pretty much all consumer infrastructure service providers rely
on, though. One guy reports that his internet is out? Probably his fault. Ten
people in the same area call in to complain in a one-hour period? Probably
yours.

------
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> )

------
gearoidoc
I wish Joel would go back to blogging about software dev in general rather
than writing what I consider plugs for Trello.

------
debacle
> 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.

~~~
ArbitraryLimits
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.

~~~
roc
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.

------
SoftwareMaven
Decreasing time between deployments is not guaranteed to always be a good
thing unless you really do "work on deployments", which may not be best for
your product.

Consider Firefox moving to six-week deployments and the negative impact it
had. That could have been mitigated by a "work on deployment" that added value
to a product.

Many enterprise software packages are painful to deploy. Having worked on
these, I can tell you it is because hooking up a dozen systems is just
complex. You could conceivably have a way to make that turnkey, but that
"working on it" probably would not be good for your product as enterprise
customers understand (and usually appreciate) the slower pace.

Somebody else said don't go cargo cult with this. I couldn't agree more, but
certainly think about it, understand where it is wasting you money, and fix
it.

~~~
wtracy
Yes. This is a spot where Joel's analogy breaks down.

When a factory/bakery/whatever ships product, that's capital that's
immediately converted to a liquid asset (cash). Unless your customers are
paying per-feature as they are delivered (when does that ever happen?
contracting?) software really doesn't work that way.

~~~
tedunangst
When your customers are paying for upgrades via support contract, and they
don't get upgrades, they stop paying for the support contract. People have
short memories, they need to see signs of activity. Delivering features they
don't want gives them more hope that you will soon deliver the feature they do
want, vs delivering no features at all.

------
d4nt
This concept reminds me of "Technical Debt" in that its a way of expressing
what the software development world has found to be best practice in terms
that an outsider/business-person would understand.

------
neves
He just reinvented Kanban:
<http://en.wikipedia.org/wiki/Kanban_%28development%29>

------
gruseom
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!"

------
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.

------
grecy
> 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 inventory, because the
money you "free up" kind of looks like revenue, which you are obviously trying
to increase. Continuing down this path has no future.

At some point you can't reduce inventory any more (lets even say you get it to
zero with JIT), at which point your "revenue" will "fall" compared to last
year/quarter and everything looks bad.

~~~
mcherm
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.)

~~~
aggronn
More concisely (or generally, or just nebulously), it represents an
opportunity cost.

------
michaelfeathers
Joel 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...](http://michaelfeathers.typepad.com/michael_feathers_blog/2011/05/the-
carrying-cost-of-code-taking-lean-seriously.html)

------
damian2000
Good 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.

~~~
jes5199
This is valuable enough to justify writing the tests, isn't it?

~~~
rwallace
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.

~~~
karlmdavis
> Cutting your deployment time is equivalent to saving a one-off cost.

No, cutting deployment times produces ongoing savings in two respects:

1) Time is saved on deployment every release. That may be a small amount
relative to the engineering that goes in ahead of releases, but it's
definitely not a constant: it's proportional to the number of releases. When
one considers not just major-version-every-six-month releases, but also
maintenance releases, hotfixes, patches, etc., the time savings is increased
even more.

2) As Joel discussed in the post, there are lost opportunity costs when a team
develops a feature and does not immediately release it. Presumably, those
features are intended to directly or indirectly increase sales/revenue: the
sooner they are released, the sooner they can begin making the company money.
This money is proportional to the number of features/improvements.

Investing the engineering effort required to achieve a shorter release cycle
doesn't always make sense, but it definitely always produces value
proportional to elapsed time.

------
donmcc
Wherein Joel espouses an agile software development methodology and invokes
the Toyota Production System.

And pictures of Taco the Husky are always appreciated :-)

------
marcamillion
> (PS No, this is not “waterfall.” No it isn’t. Is not. Shut up.)

I love Joel's writing style.

------
Sherlock
This looks about right for any kind of business, not just software
development.

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

~~~
gecko
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.

~~~
kinleyd
Heh, thanks. Nice to know that Taco can be as fast as a bullet when the
opportunity presents itself. :)

