Software Inventory by Joel Spolsky • Hacker News Board

Re: Software Inventory by Joel Spolsky

#41

Post by keithpeter » Mon, Jul 09, 2012, 6:25 PM UTC

SoftwareMaven wrote: post #25

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…

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

Re: Software Inventory by Joel Spolsky

#42

Post by codinghorror » Mon, Jul 09, 2012, 6:32 PM UTC

SoftwareMaven wrote: post #26

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…

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

Listening to your customers is the greatest skill there is. But that doesn't mean the customer is always right, either.

Re: Software Inventory by Joel Spolsky

#43

Post by codinghorror » Mon, Jul 09, 2012, 6:34 PM UTC

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?

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

Re: Software Inventory by Joel Spolsky

#44

Post by aggronn » Mon, Jul 09, 2012, 6:38 PM UTC

mcherm wrote: post #31

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

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

Re: Software Inventory by Joel Spolsky

#45

Post by benjiweber » Mon, Jul 09, 2012, 6:55 PM UTC

damian2000 wrote: post #3

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.

Deployment cycles in hours or minutes are quite possible with a decent set of automated tests. It's called continuous deployment.

Re: Software Inventory by Joel Spolsky

#46

Post by bchallenor » Mon, Jul 09, 2012, 7:00 PM UTC

mcherm wrote: post #31

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

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.

Re: Software Inventory by Joel Spolsky

#47

Post by wtracy » Mon, Jul 09, 2012, 7:52 PM UTC

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.

Re: Software Inventory by Joel Spolsky

#48

Post by tedunangst » Mon, Jul 09, 2012, 8:03 PM UTC

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

Re: Software Inventory by Joel Spolsky

#49

Post by tedunangst » Mon, Jul 09, 2012, 8:07 PM UTC

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…

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.

Re: Software Inventory by Joel Spolsky

#50

Post by karlmdavis » Mon, Jul 09, 2012, 8:07 PM UTC

rwallace wrote: post #19

jes5199 wrote: post #7

Earlier quoted context omitted.

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

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

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