1.30.2009

beta blues.

My company is on a yearly release cycle. So from May to December, we work on features for the year. In January, we tie up the loose ends and release a beta version of the new version of our product to certain users. They use it and give us feedback. We fix things and release another beta a few weeks later. They use that one and give us more feedback. Finally, we release the final product in the spring sometime, and the whole thing starts all over again.

The nice thing about this sort of schedule is that you can sort of predict what work is going to be like at any given time of the year. In November and December, it's very busy and tense and stressed as people try to finish up features in time. Some of that leaks into January, though not for everybody. During the summer, when you've just been assigned your features and you got like six whole months to finish them, it's very relaxed.

If you've been paying attention and are good with calendars, you'll realize that right now we are in beta. This can be a stressful period as well, but in a different way.

First of all, the software has bugs. All software has bugs. Some of them are incredibly obscure and may never get found. At my old job, we found a bug where if you were using the program, then just happened to change your screensaver and then just happened to try to close the application after that, it crashed and burned. A crash is something to avoid, but seriously, how many people are likely to change their screensaver at the moment they're using the program?

We do test our software here. But we could never come up with every single possible usage of the application, just because it's a pretty complex one. So we rely on the beta period to shake out some of the common things our users will run into. We also take suggestions for improvement, for instance in the way something looks or behaves. We get feedback mostly from our user forum. Users who are using the beta log on and create a topic for a bug or suggestion. We respond, asking for clarification or telling them that we were able to reproduce the bug ourselves and will fix it.

Of course, the first day we release the beta, there is a floodgate effect. We release, we have a couple of hours of peace, and then all of a sudden users are adding bugs left and right. This user has a problem with this feature on UNIX, and this one thinks this tool is hard to use, and another one thinks we should add an option for something or other. What is stressful, for me at least, is the way I get pulled in several different directions. I only have to really respond to reports that deal with something that I worked on in the first place, but I might have half a dozen of those come in within a couple of hours. I read a bug report, I see if I can reproduce it, I respond to the user, I enter a ticket in our bug tracking system, and finally I get down to fixing the problem. By then, several more might have come in. I just need to focus, is all.

The nice thing about beta is that it sort of allows you to polish your features. After a couple of weeks, the reports from users starts to slow down a little, and you can catch up. You might even finish with all the stuff those nagging users asked for and have time to add a little polish of your own. There are always things that were required to be finished before the feature could be called "done." And then there are the other things you might have thought of along the way that fell into the "nice to have" category. I suppose it's sort of closure.

So that's your day in the life of a programmer. At least this particular programmer in January.

No comments: