More Eating Your Own Dog Food And Daily Builds

I have just been reading an article on the importance of scheduling and bug and feature tracking in software projects.  Its a good article and worth a read, but its basic stuff really.  However it’s often the basic stuff that gets neglected so don’t dismiss it on that basis.  Anyway the article prompted me to think a bit more on the benefits of eating your own dog food and regular/daily builds.

The key thing I missed in the previous article was the importance of the process to managing compromise, and often that compromise takes the form of cutting or dropping features in order to deliver to time and budget.  The daily build/dog food approach helps with this as follows:

1. First it’s pretty key on all projects to put the basic platform elements in place first. These are the foundation elements upon which everything is built; they need to be the most reliable and therefore tested for the longest period.  They are also needed normally before any realistic dog food environment can be created.  In my desktop example this basic building block would be a stable system image, with a core set of applications.
2. From that point onwards you are into the features management game.  Using the environment daily and releasing updates regularly helps because your user/testers will start to provide feedback on the features they really need to deploy, use and manage the environment, where there is a mismatch between this feedback and the prioritised feature list (make sure you have one of these) the development team are working to this can be really useful.
3. The second reason it helps is because when the development team provides an early release of some really sexy feature, if the user/testers hate it or never use it, then it’s pretty likely that you need to take a hard look at whether it’s worth proceeding with it at least in its current form.  If you do the daily build process right you could get this early feedback with maybe only 20% of the effort that would be needed to finish the feature so there is a good chance of making real savings
4. It’s also likely that the architects have specified some really tough challenges to the engineering team to achieve ‘elegance’ that no user of supporter of the environment is going to appreciate.  Dog food users are a great community to help you spot this sort of thing.  Sometimes its also called ‘over engineering’, although that’s slightly different.  Dog food user/testers will also spot over engineering as well because at some point you can elicit feedback on whether the current functionality is ‘good enough’ if people are using it and not complaining that’s the time to ask the question.

Here are a couple of other points I missed as well:

1. Another observation that’s VERY applicable to software development but helpful in system integration is that it’s MUCH easier to fix a problem the day after you wrote the software than it is a month later when you do the integration test.  In system integration its much easier to change the design the day after your users say they hate it than it is when that design implications are embedded in tens of documents and lots of system implications have effectively made it impractical to change.
2. The final observation is that the objective of developers should be to have the minimum number of bugs outstanding or unknown; with daily builds provided you fix everything as it happens this is generally true and so the system matures with only a handful of outstanding bugs at any point in time.  This minimises the risk of fixing a bug causing other unanticipated problems and makes regression testing much easier.  If you wait until everything is finished you end up with hundreds of bugs/issues to resolve and for every 10 you fix you create 3 more.  In systems integration projects it’s not so much coding bugs that you minimise it’s risks associated with not knowing if systems actually perform as documented.  Anyone that does a lot of systems integration knows that no application works as documented, and the more applications you string together the more difficult it is to get any complete business process to work.  Even worse if you are using a closed source product its quite unlikely that problems you find will get fixed in time, so you often have to find workarounds or change the architecture or design completely.  Finding these issues as early as possible is key to delivering a quality product to time and cost.

This dog food idea works for documents as well, often projects write documents that only the project team think they need, or the managers of the people who will use them think they need.  It’s a really good idea to send skeleton/outlines of your documents to the real customers of the document and maybe a good example of a previous one, so you get feedback from your customer.  An associated tip is to deliver a website rather than a document.  Websites have obvious advantages some of which are worth repeating:

1. They are easier to navigate
2. There is less duplication
3. You can read a high level outline of a topic/process and dip into the detail through a hyperlink
4. They can link to referenced documents that most readers of normal documents would never be able to locate and therefore never read
5. They can link to applications, utilities, file system folders etc.
6. The overhead of writing a web and getting it issues as part of a collection of pages that make up a site is MUCH less than the overhead of getting documents through a formal review process
7. If you want to get clever setup and RSS feed for your web site so that interested parties can subscribe to changes in its content.  Architects and engineers can subscribe to the changes as well during development and also to keep track of changes once the system goes live to make sure operational changes do not compromise the systems integrity.
8. If you really want to get clever deliver it as a wiki so that the end customers can enhance it with their own content and experience

The picture is of The Deep marine experience centre at Hull, close to where I created my first HTML document using an open source web browser, long before there was really a real Internet