Hacker News new | past | comments | ask | show | jobs | submit login

The points are good, but missing the elephant in the room: when you are competing with the best companies in the world in software (where the marginal cost is 0), you simply can't afford to compete using anything less than the best stuff. You need to go 'deep' (specialist), rather than 'wide' (mass-market) when it comes to the tools you yourself use. (Even though what you're creating is probably itself wide.)

That's why Microsoft doesn't use it's own source control solution (SourceSafe) internally. It just doesn't cut it.

That's why Apple doesn't design the next iPad on an iPad.

That's why McDonald's executes don't hold their business meetings in a McDonald's, to close important international deals etc.

You just can't afford to. This guy says "At BugHerd, we build a project management tool for web projects. BugHerd is, itself, a web project."

Imagine you just wrote the first version, and you realize that it sucks. How will you track the transition to the second, non-sucky version? If you're using project management software - the one you've just written - that by your own admission sucks?

That is a formula for disaster.

But the very same argument (for not using a disastrous tool) applies for the continual marginal improvement that better tools can give you.

It makes ZERO sense to 'bootstrap' any tool using that tool except for some special exceptions.

That doesn't mean you shouldn't test it :)


Some exceptions:

1) The tool is the only one that exists. Even a buggy version that takes 10x longer to produce a halfway decent result would still be the only thing that exists.

Perhaps the first compiler was like this: i.e. the first time someone translated paper into a compiler, it made sense to use that buggy version to recompile itself with optimizations. But that's because it was the only one to exist.

2) if you are now the best on the market, period. So, if you so happened to create the best tool on the market, sure, go ahead and use it.

3) if you are on par with the best. This is tricky. You can learn a lot from the competition. It hink in this case you should use both. Gimp might be 'on par' wtih photoshop, but I really think that Gimp developers should use both on a daily basis. It's amazing what kind of a perspective access to being an occasional user of your competition gives you.

I almost quit a job after having to work out a solution to a real-world problem dogfooding a product that was, at that time, really shitty. The problems with that version were known and the roadmap for the next one fixed, so no value was added except that some manager could boast about dogfooding. However, my mood was very, very dark during that time and quite some time after that. In hindsight, I should have just quit, and I would in a similar situation in the future.

I thus consider all dogfooding unethical that is not done by somebody who has, or is provided with, a lot of influence on the product.

You bring up a good political point actually, glad you brought it up.

Apple doesn't use it's most mass-market product, the iPad, to develop the next iPad. But it does use Macs, probably even where they're slightly worse than PC's. If some kind of developer at Apple really needs a Laptop with 64 GB of RAM they probably can't get away with it without a very good justification.

This does, however, have objective benefits as far as company image, esprit de corps, promotion, etc.

But Apple might be a special case.

I guess it comes down to whether you're building just a tool or a lifestyle image.

If you're building a lifestyle product, then sure homogeneity or self-promotion has a huge objective value to the company.

Regarding 3):

They _really_ should. I have a feeling they dont use it at all for actual task (except for testing out if something works)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact