Home > Programming > Version 1.0 Woes

Version 1.0 Woes

September 19th, 2008 Leave a comment Go to comments

I’m putting the finishing touches on a project I’ve been working on for the last 2 months. As with any semi-serious non-government contract projects I’ve worked on, the end is always painful. Did your original design meet the original demands? Is the demand still there? What have you forgot to test for? And of course the problem I’m running into now: I really want to add features to make this the most robust piece of software ever (emacs, anyone?)…

As with anything, the desire to make something really great is a hard feeling to suppress. It’s almost feels like punishment to hold off from putting in a feature that would fit in more nicely with the Web 2.0 crowd.

How do you know when to hold back and when to introduce a new feature, you may ask? TIME

Time, is the only factor that really impinges us from doing everything. If it weren’t for time any great programmer would write an OS, but of course that’s not the case, and time is the huge crutch that you have to work around. When working for a company it’s easy to know when your “time is up.” The funds for your project will just stop showing up one day, or a requirements review will come your way.

Yet a more significant challenge is how to know how much time you have in a self-guided effort. And the rule I’m sticking with now is, get 1.0 out and then work on adding the newly thought-up features after you have the clients to gear it towards. Then, you’ll get feedback on the features while you add them and the features will be all the more useful.

Of course, the next problem with holding back from adding features is it could limit your ability to acquire a client, but in reality all you have to do is make sure to not promise a version 2.0 with X features at Y date, when 1.0 is ready to go and solves specific business problems. Because then you risk having the client wait for the more improved 2.0 version, thinking 1.0 won’t suit their needs.

1.0 feels limiting, but make sure its limited scope solves a real business problem and sell on that promise. And don’t sell more than you’ve got.

Categories: Programming Tags:
  1. No comments yet.
  1. No trackbacks yet.