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.
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".
"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.
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.
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!
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.
>> 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.
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:
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.
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?
For a completely community-driven site like SO, that might work.
For anything else, you will never be a leader in the market with that attitude. The reason why it seems to work early on on a company is that you are resting on the laurels of the original vision of the software. That will get washed away in a sea of tweaks to existing features by the community.
Customer feedback is an important consideration, but should not be the only. Believe it or not, product management is a valuable skill.
The problem here is that the propensity to add bugs and features is disproportionate across the user base. Some people get a kick out of adding feature requests and being 'noisy'. Some people have an important or good idea but will never take the trouble to post it.
The problem, then, is being able to sort between this and not only (a) keep the active community members on-side and (b) find a way to flesh out those hidden requirements from less-engaged people.
Of course the other issue is when community requests are not necessarily profitable for the company that provides them.
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.
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.
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.
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.
Yup. It forces you to prioritize, and if you don't have that constraint you will be forever overloaded and overwhelmed; Things that no longer have the same value or relevance may linger in your mind through the reminders of scanning the backlog + psychologically, having a mountain of things to do feels like a mountain of things to do - there's no need to remind yourself of those, as if they are important enough you will remember them, re-visit them, they will re-surface.
I don't know if throwing away is a better mechanism. I feel the throwing away should also include at least some justification of why it was not important as compared to what you already have on your plate. This will help when the same feature request/bug comes back again.
Software landscape changes much more frequently these days. A feature that did not make sense a couple of months ago might be much more appealing today. Knowing why it was rejected in the past would help some channel the discussion better when it shows up again. Also it would help recycle the brain cells that were spent on it last time.
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.
For anyone interested, check out the Implementing Lean book:
And the rest of the Poppendiecks' books too. They're all good.
I have to say, there's way more wisdom in the more mature 'lean' world than there is in the trendier 'agile'.
I'd disagree with that. Its just that agile has suffered the curse of becoming popular - so there are lots of folks/tools out there who have the label agile, but none of the meat.
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.
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....
> 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.
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.
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 )
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.
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.
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.
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.
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.
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!"
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.
> 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.
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.)
True, though the factory's owners (its shareholders) assume that the factory will beat the return of the market as a whole, and the rate of any loans they have. Otherwise they'd just invest in the market, e.g. via an index tracker. So for them at least the opportunity cost is a little higher.
Interestingly I had a friend who had a business in the bulk flour business.
They were moving enough stock but profits weren't coming through.
We did some analysis on cashflow and stock and found that the sitting costs of too much flour were eating cashflow. Basically he was paying upfront for bulk flour and then receiving the cash from customers over 60 and 90 days. One of the costs of holding too much inventory is real estate - bulk flour costs floorspace to store. In a low-margin business, just a few percent here and there can turn something from profitable to loss making pretty easy.
That's not really applicable to software, which is generally a high margin business, but having too much inventory is definitely a problem.
It's not about reducing or increasing revenue, it's about trimming down the size of the balance sheet.
An important economic concept is return on investment. Generally speaking, the main goal of business owners is to try to maximize dollars earned/dollars invested.
High inventory costs increase the denominator, which reduces ROI-the very thing you're trying to maximize.
This all assumes that capital is your main constraint. But you can apply the same concepts to any other constraint. For example, if you're trying to maximize dollars earned/hour of labor, you want to minimize the amount of labor tied up in inventory.
Your raw profit (not revenue) may fall, but there are lots of other numbers a decent investor will look at. Total profits make for good headlines and bad analysis.
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:
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.
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.
> 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.
> Cutting your deployment time is equivalent to saving a one-off cost.
I don't see how that's true! Could you explain it?
My experience is that short release cycles mean better feedback loops, which means quicker bug fixes and less flail about deciding what features to spend time on - so you get an ongoing improvement in speed.
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.
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.