Posted on

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.

Posted on

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.

Posted on

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)?

Posted on

I’m Going To Run My Own Software Company

Welcome to the “Joel Of All Trades” series.

170920081464

Doing your own thing means that, in my experience, you have to be a Jack Of All Trades.

You come up with the idea for a piece of software. You do some design; database, UI. You write it. You use it.

Then the real work kicks in. You need web presence. Marketing. Relationships. You need a Support system. Bug and Feature tracking. An Alpha/Beta system.

You have to get a website. Make the decision about what to put on it. Screenshots. Features. Some kind of “look at me” frontpage. Images.

It’s a big job. And it’s not the end. Because, all of the before is only a foundation for the following:

You have to sell it.

This series, Joel Of All Trades will chronicle my own journey. A journey which begins with Oldaer.

The series name is in reference to Joel Spolsky, who inspires me every time I read his blog. Check out this post, The new Fog Creek office.

Oh, the Aliens in the picture above obviously have a very excellent plan for World Domination. They have Dragons. There’s a metaphor in that somewhere.