Joel, on the merits of dogfooding:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2005/05/the-difficulty-of-dogfooding.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2005/05/the-difficulty-of-dogfooding.html
Thats some good advice. I was definately “dogfooding” for the apps I built at work. 
Dogfooding works best I think for ‘consumer’ apps, not really vertical market apps. For example, I use the latest build of my RSS aggregator every day and I find most of the bugs and usability issues because through this. When I tried to use the first beta build I did, I discovered to my horror the app missed a few simple, but critical, usability requirements. Every day of use I can make it a much smoother experience.
I completely agree with the article, although it shouldn’t tell any self-respecting developer anything they didn’t already know.
Curiously enough, I used to live with a guy who worked for a pet food manufacturer - designing dog food. And yes, he literally did eat his own dog food every day. :d
I dont think this is the way to go for most projects after all. Of course it’s the easiest and clearest way of testing software and the developer has the most direct feedback connection, namely himself.
But I think the majority of us is working on projects as pointed out that the developers dont have any idea how and field where to use it.
As for me, im developing software in semiconductor business for highly qualified ppl and i really dont have the time to learn their job too. Most of the algorithms come from the maths guys in form of dozens of lines of formulas and i dont really think ill be ever able to test those. All i see are tons of numbers coming in, getting processed and tons of other number getting spit out at the other end.
Afterall developers should focus on developing the software. I think its worth to cleary seperate the testing from the development, done by the ones that are really expected to use it once its done. Though its really difficult and expensive to seperate but let me put it like this: if the only feedback on the taste of the dogfood comes from developers they will tend to create something like a pizza-cappucino-dish-dogfood and im quite sure that the dogs wont like that too much as final product. …hm but the article already points that out. So i agree on this
I think the dogfooding is a good idea - where applicable. I definitely have to agree with your post too, though. The application I am developing and maintaining during my day job does not really lend itself for this practice: I am clearly not member of the intended audience AND the application does require the aforementioned specialized industry knowledge. I and other members of my team do however create our own internal utilities that are supposed to make our jobs easier. There dogfooding makes a lot of sense.
I think dogfooding is great, and really helps build credibility (http://timstall.dotnetdevelopersjournal.com/becoming_a_credible_developer.htm). After all, if you won’t even use your own project, why would others. I also like your points on why someone would not dogfood it.
If you aren’t making the software for yourself, who are you making it for?
I’m a little befiddled by this distinction between developers and users. Are developers so lost, so far and deeply indoctrinated into developing programs that they just forgot how to use them?
It’s the other way around. Developers know too much about the program, that the operation of it is obvious to them, even when it’s not obvious to someone who is new to the system, and doesn’t know how it works. Imagine, for instance, you’ve never seen a typewriter keyboard before, and you encounter one of these Das Keyboards:
http://us.st12.yimg.com/us.st.yimg.com/I/yhst-40922258946781_2033_1377936
Sure, if you already know how to type, it’s no problem. But if you don’t, how do you know where to even start? This is a developer’s keyboard. Not a user’s keyboard. It’s the same situation with software features that a developer has devised. You have to test with real users!
I wonder, would it not be obvious to the developers of that keyboard that you cannot see what key makes what sign? Surely I’d want signage on a keyboard I’d have to use, for the first time even. In fact I’d want a little guidebooklet to tell me what all these weird ‘shift’ and ‘ctrl’ keys do and a little backstory to better understand.
Can’t developers think this far with software? Can’t they make software they’d want to use themselves, feigning ignorance of computers?
If you aren’t making the software for yourself, who are you making it for?
I’m a little befiddled by this distinction between developers and users. Are developers so lost, so far and deeply indoctrinated into developing programs that they just forgot how to use them?
You’d think so, using common sense, and folk psychology. The problem with common sense though, is that it’s frequently wrong. Aristotle was wrong about physics, and newton was right about physics (physics at the human scale, anyway)
So no, very frequently the developer of the system is precisely the wrong person who should be designing the interface or writing the manual. They just know the system too well, and will inevitably assume too much knowledge on the part of the user.
@BmB
Remember, nearly every business in the developed world now requires applications, some of them specialised. These businesses may not be IT related but require custom software. They outsource this work to a development firm.
Question answered?