Bugbase Driven Development

Problem

You want to document in real time, so you don't end up like that one project where the new team members read the [BigRequirementsUpFront] documentation and made all the design mistakes, but you don't want to waste time that could be devoted to project growth.

Solution

Dispatch two (or more) avifauna with one lithoid missile; lean on the bugbase for the documentation system. Encourage everyone to converse, in prose, about bugs & dark corners of the system, in that bugbase, to keep the project information widely dispersed among the personnel.

First, you install a bugbase, such as BugZilla, BugaBoo, Insecticida, TestTrack-Pro, JitterBug, ExtremePlanner, FlySpray, RedMine, TracProject / TracWiki, TargetProcess, GitHub, etc, etc... literally any one can do: you can roll your own as part of the project with only the slightest overhead.

Then, you hash together whatever works, in the code, in a garage, and spooge it out as Beta 1. With a few light topics such as "screen with buttons that turn it on" type stories; the obvious stuff nobody pays attention to.

The Beta 1, however, naturally becomes the mother lode gold mine of new issues of every stripe. You harvest dozens of bug reports and feature requests, from idealized and/or real customers.

Everyone learns early to mercilessly refactor the bugs, to read them a little & pass them on, adding their wisdom & subtracting value from the system.

Then, for each one, you prioritize it onto a carousel daily, as team members pluck tasks from its other side.

They only write code if they have a bug to fix, and they only deploy if hordes of manual testers thumbs up their assigned bug portfolios.

The bug reports reference each other, groom each other over time, amanuenses of the project archeology & outlook.

The lowly bugbase has now grown to be the central & number one knowledge base and living hive of the community.

CategoryAntiPattern; CategoryOrganizationalAntiPattern