Eating your own dog food

September 5, 2008

I’m currently reading “Practices of an Agile Developer” which is part of the “Pragmatic Programmers” series of books. It contains many great ideas and tips on how to be a better software developer and is an excellent followup to the original, and now almost iconic, “Pragmatic Programmer” book.

When I’ve finished I’ll put up a full review. For now I thought it worth noting one point which caught my attention, the idea of “eating your own dog food”. As you can see from the wikipedia article, this is not a new idea.

This is something that I’ve been attempting to put into practice throughout the LCFG buildtools project. As soon as the tools I developed became capable of actually managing the releasing and packaging of software projects I’ve been using them to do just that with the new buildtools packages. At times I’ve wondered if the extra effort would be worth it and it has got me into some awkward positions when the tools at hand are broken and putting the fix into place is made more difficult by not being able to do straightforward releases. The big advantage is that by actually using the tools extensively I’ve developed a really good idea of what works and what just sucks. There is no better way to check if the high-level design is correct than to use the system in its infancy. The build tools also have unit tests which will say if an individual piece of code does the right thing according to some specification but they will never be useful for judging whether a tool “feels right”. This has undoubtedly led to the new tools being much better equipped for building software packages for projects which are not LCFG components, that’s not to say that the packaging of LCFG components has been in anyway ignored, of course. In a way this has also provided a form of continuous integration testing, I’ve typically needed the latest submitted version of the tools to be working in some form at all times to get onto the next stage.

I think it’s clear that taking an “agile” approach has been much better than the more traditional methodology of doing all the design up-front, coding up the design and only then doing full usability testing. Up-front planning is absolutely essential but I think it needs to be kept to a high enough level to make it possible to see how the development can be split into chunks, each focussing on separate pieces of functionality. For example, I first worked on being able to use the tools to tag releases, once that was working I started using it and moved onto adding support for packaging. At the beginning of each chunk that work is planned in more depth and, if necessary, prototypes are developed to test ideas before full development commences.