Dogfooding is good - it certainly changes how you think about things anyway.
It isn't sufficient for good software, but may be necessary -or at least when possible (sometimes you make software that has no direct application to your life...).
By this I mean bringing concepts such as testing directly into programming languages. It isn't enough to say what a program should do, we need to say what programs should not do as well. Some languages have tried (Eiffel?) but failed. Some approaches have worked but have put the effort in the wrong place (e.g. JVM enforcing bounds checking) or by making it too powerful in the wrong ways (e.g. aspect oriented.)
Go takes a step in the right direction by introducing unit testing directly into the tooling. But that's not remotely enough.
Agile doesn't solve the problem either, because it focuses on the idea of a releasable product every few weeks. Living the reality of agile, I gotta say, it falls on its face a lot. Sure, you can make some microscopic change to your product, but then QA has to do a full regression every 2 weeks.
Surely software engineering can do better than this.
That's all I have to contribute to this discussion.
