Don’t Beta During Your Own Beta
I use a piece of software that’s currently going through a beta period for it’s next release. It used to be that there was a new beta release every couple of weeks, but then that was reduced to every month. This was fine with me because I often didn’t have time to install every new beta. However, the second beta had some serious problems and so I had to return to using the first beta. One month after the second beta, there’s still no sign of the third beta and the natives (users in the support forums) are getting restless.
The reason for the delay? The developer decided to switch to the latest version of the IDE/Language/Framework and some of the third-party components being used aren’t compatible. So now the developer’s in a bind and has to either fall back to the previous version of the framework, or try to get the problems with the third-party component resolved. This means another several weeks or more will go by before things are stabilized enough to put out another beta.
The moral of this story is that while you’re in the beta cycle, you should minimize the changes to your tools (IDEs, frameworks, components, libraries, operating system, etc.) so that you can focus on getting your product out the door. Doing otherwise is like trying to add a turbo-charger to your car’s engine while you’re driving.
On the other hand, sometimes you need to upgrade one of your tools because of a bug fix or a new feature that you really, really need (this is more like pulling over to the side of the road to change a flat tire). In that case, change only one thing at a time—don’t try to change other tools just because you’re already on the side of the road: that’s no place to be doing major overhauls. Wait until the next release when you’re safely in the garage and have the time and tools to ensure that you can do a quality job.
