I mentioned in my last post that I spend time thinking how I would run a software group if I could start from scratch. I won’t touch on how one retrofits this into an existing organization with institutional inertia (see previous entry on monkies and firehoses). I wanted today to talk about the tools I think are critical to a team.
[Note: I wrote this orginally at 30,000ft on my way to Jaxonville, FL so there are no links to the products below. I will try to come back and add them later. Updated 12/12/2008 with links]
Source Control
This is non-negotiable. Whether you use a commercial tool like Perforce or open source tools like Subversion, you must have this. It needs to be the right hand of all developers, ingrained into their daily habits. All code must be checked in at every opportunity. If working in a shared codebase, one must be careful to not “break the build” but developers should plan their work so that it can be done at least once a day if not more often. This takes discipline but if the habbits are developed from the start, it will pay off in the end.
Online bug/issue tracking
Tools like Bugzilla allow a team to keep track of problems and tasks pending while giving project managers and senior management a view into the project that can be tracked over time. But in order to be used, the system needs to be simple and straightward to use. The instant it becomes burdensome or even annoying to use, it will become neglected and not used. This applies to data entry, searching, and reporting.
Wiki for documentation
This probably the most controversial. It is my believe that using tools like Microsoft Word are horrible tools for collaborative document writing; exactly the thing you need for the creation of the most important documents in a software project; requirements documents, functional specifications, technical design documents, test plans, and more. Word docs get emailed around, changed by different people at different times with little tracking in place. More time is spent in document management than in actual content creation.
How does a Wiki solve this? You get a central document that anyone can access and edit without emailing them around and having to reconcile changes. It provides change control and tracking so you can see who makes what changes. It also has the built in capability to link between documents to show the relationship between a design section, it’s corresponding functional description, and the requirement it is supposed to fulfil. Many wikis also have the facility to host discussion forums tied to a document but seperate from the content itself. There are obvious challenges of freezing the document at key points in time I believe this is small in comparison to the benefits.
I have never been able to implement this particular idea but I am convinced it will make everyone more efficient.
(And, yes, a wiki can be used for so much more and it should, but that rarely takes as much convincing.)
While I don’t have a huge readership here, I know most of them are software people, so what do you think? Anyone have a great idea and the money to let me give it a go?