A common question that comes up on the
For my own personal set of libraries and applications I naturally have very simple needs. Generally speaking all I want is a one line description of a bug or feature. Consequently every library and application has a simple text file called TODO.txt that is (often) an unordered list of features. One of the good things about keeping this file in the repo alongside the source code is that it changes as each feature is implemented. Generating the release notes is then as simple as picking out all the diffs of that file since the last release label.
More recently Iíve started using an online service (GitHub) to host my source code repos. Being a service aimed at project hosting, each repo automatically gains an Issues database and Wiki. The database of issues provides the next step up from a simple text file as you can track the status of features in more detail, such as whoís assigned to it, which release itís destined for, etc. Because itís integrated with the source code repo including a number such as ď#42Ē in the commit message creates a link in the GitHub UI to the issue with the same number which is good for software archaeology later.
At the other end of the spectrum are the
Itís a noble pursuit to try and ensure that every code change, and therefore every commit, is related in some way to a formally tracked feature, whether instigated by the business or the development team itself, as that helps keep everyone honest. However I find enforcing that kind of policy increases the pain of checking in out-of-band changes, such as to the build process, and only succeeds in enticing developers to bundle unrelated changes instead. If the tool makes adding a new feature request tedious then itís not going to be used the way you might prefer.
Outside the realm of dedicated 3rd party feature tracking products are the home grown alternatives. Naturally Excel, the Swiss-army knife of the corporate world, has been pressed into service on many an occasion. Despite it being painful to enter or read blocks of text with more than a couple of words, its ability to easily produce charts seems to be a big consolation prize in some circles. The agile project managerís fascination with burn-down charts and the like might fuel this choice.
What is probably the most derided part of the Microsoft Office suite Ė the Access database tool Ė is far more suited to the task, or at least was a decade or so ago. The only time Iíve ever actually created a database in Access was to knock up a simple bug tracking database for a very small team I was in. Iíd seen someone do it before at another site Iíd worked at and when the team grew large enough for the single-user problems to start becoming a drag it was easy to migrate the underlying database engine to something more heavy-duty, like SQL Server. With the plethora of free options available today the days of writing your own issue tracker have almost certainly long gone.
In more recent times Iíve had the pleasure
of using another of the
At the TICOSA conference  I mentioned in the last edition of this column  there was an interesting question about where to store the supporting documentation for a feature. Whilst the code might be a good place to document some specific details about the current implementation, it isnít necessarily the best place to ďRecord Your RationaleĒ . For this a wiki might be more appropriate or, if the document requires some richer content such as UML sketches, then storing them in the repo itself in a separate docs folder also keeps them close to hand.
The last 12 months has seen me working on a
Whilst a project managerís perspective of a feature tracking tool will likely be biased towards prioritisation and progress, as a developer I find I have different perspectives depending on the state of the feature. Prior to implementation I also want to know what the most important feature is along with details of acceptance criteria, etc. Post implementation Iím often looking for a way to trace a change in the source code back out to the driver for it so that I can better understand its context. This helps makes subsequent changes a little safer, especially when tests are scarce such as in legacy codebases. Sometimes, such as when a serious piece of technical debt has been accrued, I raise a ticket and embed the ticket number directly in the code to make it easier for a future maintenance programmer to track down the supporting notes in case Iím not around when they finally decide to pay it back.
 C Vu 26-1, March 2014
15 June 2014
Chris is a freelance developer who started out as a bedroom coder in the 80ís writing assembler on 8-bit micros; these days itís C++ and C#. He also commentates on the Godmanchester duck race and can be contacted via email@example.com or @chrisoldwood.