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

21–30 of 65 posts

Re: Software Inventory by Joel Spolsky

#21

Post by raganwald »

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?

Re: Software Inventory by Joel Spolsky

#22

Post by jpadkins »

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

Re: Software Inventory by Joel Spolsky

#23

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

Re: Software Inventory by Joel Spolsky

#25

Post by SoftwareMaven »

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

Re: Software Inventory by Joel Spolsky

#26

Post by SoftwareMaven »

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 should not be the only. Believe it or not, product management is a valuable skill.

Re: Software Inventory by Joel Spolsky

#27

Post by bobbygrace »

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…

That's what the Trello team is trying to do on the public Trelo Development board. https://trello.com/board/trello-development/4d5ea62fd76aa113...

Re: Software Inventory by Joel Spolsky

#28

Post by jes5199 »

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.

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.

Re: Software Inventory by Joel Spolsky

#29

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

Post reply on HN