Simple Bug/Feature Tracking With Google Docs

When you design small systems, there are some big benefits.

One of these is with bug/feature tracking. This is not to say that with a simple project it’s not important to track bugs and features. WRONG. It’s vital.

My point is that you can streamline your other processes, as well as those in this most simple of software you are building.

While developing Oldaer I’ve been using Google Docs to track my Bugs and Features through the builds.

How does this work? Well, very simply.

1. I have a doc called “Oldaer, <buildnumber> Todos”.

1802200913924am

This document lists all the Todos I have. It’s a relatively small amount. Important Todos are bolded. Sometimes there is a further description underneath.

2. As Todos are completed, I “mark” them off.

1802200913317am

You can see it’s a yellow background. I’ve found this is the best because of it’s immediate visibility to the eye.

Whatever you want though, it just needs to be quite distinguishable.

3. After the build is done, we copy the Todos document (using “Save as a new copy” in Google Docs) into a Changelog.

1802200913359am

To make this document a Changelog is easy. You simply remove all the Todos that were not completed for the build.

4. We then copy the Todos document (again) into the new build number’s Todo list.

1802200913429am

To make this into the new Todo list, all you have to do is remove all the completed (yellow) Todos.

There you have it. Simple. Efficient. And because it’s Google, finding specific stuff is easy.

Of course, this is not going to work in most development situations. More than a couple of people, more than a simple project, and it becomes very hard to maintain.

However, if you are creating a simple piece of software, and don’t have any bug/feature tracking processes in place, then I urge you to consider using Google Docs.

Do this, and get the basic patterns in place for when you take on a big project.

A Year Is Done, My Time As Tech Evangelist

14022009110048amI have resigned my post as Clarion Tech Evangelist.

This was not a quick decision.

Thanks one and all for your support over the last year. It was much appreciated.

I feel that apologies are in order. I had many dreams and visions of what could be done when I started the evangelist gig. Unfortunately the only one that really came about was the podcast.

Incidentally, the podcast won’t be stopping, at least I don’t see why it will. Have to talk to the other folk, but pretty sure we’ll keep batting on about how much better Australia is at sports than South Africa.

Mucho thanks to Bob Z, Bob F, and the rest of the gang at Soft Velocity. I’ll be watching (and participating in) the action with great interest.

Kudos!

Awesome Idea #345 For A Software Project

This is an ongoing series, “Joel of All Trades”. It’s named after Joel Spolsky, the best proponent of being a genius everyman that I know.

dsc00239One of the most important lessons I’ve learned over the years is this:

It’s not how many ideas you have. It’s how many realities you make.

I had written out a big long piece weighing up the various stages of Idea->Planning->Creation->Sustaining. It was beautiful. Many witty pop-culture references.

Doesn’t matter.

What does matter, enough to speak it twice in a single post, is:

It’s not how many ideas you have. It’s how many realities you make.