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.

7 "Must Answer" Questions For Your Product

This is part of an ongoing Series, “Joel Of All Trades”. It’s named after a little-known guy, Joel Spolsky, who has some kind of online journal or something.

In addition to the core functionality of your product (You know, the important bit like What It Does) there are a number of questions that must be answered.

For some Products, the answer might be a flat out NO, but they should all be at least considered.

These questions are vital for both Desktop and Web systems.

1. Registration

22012009125818am Can the User Register themselves with you?

This means asking yourself if you care about tracking Users. There are some situations where you might not want to, but I’d reckon most of the time you definitely want to be able to have some kind of User database.

Reason not the least of which is that you can strike up a conversation with the Users, on an individual level, given that your Registration functionality should capture their email address.

2. Activation (Trial/Full)

22012009125818am1 Does your Product need to be Activated?

If you’re selling a Product, you probably want some kind of Trial version. This helps the User figure out if they want it. Course, you could be awesomely popular and not have to worry.

For the rest of us Trial versions have to be Activated. And you should definitely have Internet (in addition to the User entering a code from an email) Activation.

3. Security

2201200915438amCan the User login to your Product?

The real question here is whether your Product is completely open, or not. If not, then you need User Login functionality.

A problem with having User login functionality is that it creates a sense of Security in the User. If they use a really simple password, this is bad.

Making the User more aware of the need for a really secure password is paramount. You don’t want to force them (maybe), but you want to make it very clear (and not just when they create their password, but at regular intervals) that their password is lame.

4. Data Encryption

2201200915835am Do your data files need encrypting?

If your program contains any kind of sensitive information, you should be encrypting your data files. Even if not, you should consider doing so. Your Product is Your Product. Don’t give away anything you don’t have to (like structures and wotnot).

To protect data structures you obviously have to encrypt the entire file, as opposed to just certain sensitive fields. Really, if you have the ability, do the whole file. Can’t see any benefits for certain fields, unless it’s for human readability of the raw data.

5. Backup

2201200921111am Can the User back up their data?

This is a big deal. Giving the User smart backup options means less outlay for you at Support time. I’m not just talking about zipping up the data files when they press a button (not that there’s anything wrong with that, heh).

Backup and restore should be seamless. Corruptions will happen. So plan for the eventuality. Charge the User another $x/month for the Product to send backups periodically to your “Backup” servers. Ask the User if they’d like to backup at certain points. Find some external hardware backup options, or at least put up some Help articles (videos) on using other methods of backup.

Users will not backup on their own steam. That’s a general rule of thumb because it’s true for the majority. So take the ability to decide out of the User’s control. Or rather, give them one decision to make (like When is the program going to backup, or Would you like to send your backup’s to our secure off-site servers?).

6. Import / Export

2201200921218am Can the User Import/Export data?

Are your Users coming over from other Products? Would they have a big Excel spreadsheet chock full of data? Can they get their data out for further Services that your Product doesn’t provide?

When you start talking about Development APIs (which are all the rage with Web Services like Facebook, Twitter and FriendFeed) it’s really just giving this functionality in another form.

Put and Get.

7. Support

2201200922634am Really a no brainer. Every single Product should have some Support system. Whether it’s an email address or a big system (like Kayako), you need to Support your Product.

If for no reason other than to give a better understanding of how your Product works out in the wild. Users will always find ways to push your Product that you have never thought of. Just is.

With my new Product I’m using Get Satisfaction. It’s a web service, off-site (I’m not in charge of the data, or functionality). I’m trying it with this Product because the Product is small and I don’t have the time to put together a system with the same level of functionality.

I want my Users to be able to search for questions/answers other people have asked/given. I want them to be able to suggest new ideas for the Product. And I definitely want them to report issues.

8. Help

2201200923345am In addition to Support, do you have Help? Pressing F1 is pretty much ingrained into our consciousness.

So make good use of that pavlovian response. Start putting together a simple Help file. Screenshots and instructions. Having a good Documentation tool like Help & Manual or Dr Explain goes a long way.

But more, you can meld your Help together with Support, so that for a User finding the answer to a problem is done in the same place as getting instructions of doing a certain job.

 

Wow. That’s quite a number of important questions. It always amazes me how much I forget in the process of developing my own products.

Thanks for reading!

Which of the above Questions do you think have no relevance to your Product (and Why)?

What Does Fearlessness Have To Do With Anything?

16012009112550pm

Last night, amidst getting a new version of Oldaer out, I was inspired by Will Carling. We’ve been Twitter buddies for a couple of months now. He records his opinions, and sticks the videos up on the web (mostly at Rucku).

At about 10pm the fearlessness came  upon me. Doubt was nowhere to be seen. Pragmatism too was off on vacation.

It was half three at least before I fell asleep. And in that time I’d managed to:

Every project I start is potential. There are lessons to learn, processes to follow, disciplines to enact. And there is hope.

I don’t start a project thinking it’s going to fail. I don’t begin with my mind on all the problems. On reality.

I begin with fearlessness.

Do you have moments with this kind of fearlessness?

I’ve Had a Fantastic 10 Days Off

It’s been an amazing couple of weeks.

We had a fantastic Christmas. The energy of our kids suffused itself within us (along with our own of course, heh), and we were able to enjoy days of excitement. Still going, with the New Year too.

We’ve visited friends and gone to the beach. We’ve had bbq’s and slept through the fireworks. We’ve played Mario Kart and some Lego Batman too.

And through it all, we’ve been shown the Lord’s grace. The sermons we listened to over Christmas were powerful. Our Christmas Day service particularly struck at the heart of the message of the Gospel. Our Saviour, the Christ, born to die and rise again.

Yesterday I released Oldaer to public beta. It was a big step for little ‘ol me (not sure where the apostrophe goes, should look up my christmas pressie, “The Elements of Style” book, heh heh). So far I’ve had some good feedback. Am working on a new build with some changes.

Will look to go full release at the start of Febuary.