Software Inventory by Joel Spolsky
joelonsoftware.com
joelonsoftware.com
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.
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".
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.
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.
pyroom have a suggestions tracker... the thing is meant to be minimal!
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).
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.
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...
"You can't ask people what they want because they haven't seen it yet."
(or something along those lines)
I still wouldn't...
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...
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, 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.
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 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.
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.
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.
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.
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 'agile'.
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.
IT and software shops often have no clue about what is actually stopping them from shipping product.
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.
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....
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.
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 )
I love how candid he can be sometimes. In my experience, this is true of about 30% of the backlog.
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.
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.
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.
I don't know where you work, but where I work the stuff isn't turned into money until it's paid for. That can take a little while, depending on terms.
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.
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.
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.
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...
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.
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.
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.
And pictures of Taco the Husky are always appreciated :-)
I love Joel's writing style.