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

51–60 of 65 posts

Re: Software Inventory by Joel Spolsky

#51

Post by derefr »

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

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

Re: Software Inventory by Joel Spolsky

#53

Post by SatvikBeri »

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…

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.

Re: Software Inventory by Joel Spolsky

#54

Post by bdunbar »

wtracy wrote: post #47
SoftwareMaven wrote: post #23

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

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 a factory/bakery/whatever ships product, that's capital that's immediately converted to a liquid asset (cash).

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.

Re: Software Inventory by Joel Spolsky

#55

Post by SoftwareMaven »

keithpeter wrote: post #41
SoftwareMaven wrote: post #25

Earlier quoted context omitted.

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

"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 o…

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.

Re: Software Inventory by Joel Spolsky

#56

Post by barista »

lmkg wrote: post #20

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

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

Re: Software Inventory by Joel Spolsky

#57

Post by barista »

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

Re: Software Inventory by Joel Spolsky

#58

Post by brc »

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…

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.

Re: Software Inventory by Joel Spolsky

#59

Post by brc »

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…

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.

Re: Software Inventory by Joel Spolsky

#60

Post by mechanical_fish »

gojomo wrote: post #37
jerf wrote: post #18

Earlier quoted context omitted.

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

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.

Post reply on HN