Thursday, June 10, 2004

On Software Design: The Art of Version 1

On Software Design
This is hopefully the first part of a series of entries on software design, from my point of view. The first topic I'd like to cover is what I call "The Art of Version 1" subtitled, "What Goes In and What Doesn't."

If you are not a developer yourself, you might not be familiar with all of the decisions that go into what features make it into the first version of a product, and to what extent those features are implemented.

I usually start a project by sitting down and coming up with a list of all the things I want to see in an application. This is often based on personal desires, and holes I see in other, similar applications, if there are already applications in the same space. I next will often make a roadmap, so that I can figure out what features might get done when. After doing all this, it's easily see that not all of the features can make it into the first version of an application.

Why is that exactly? Well every feature takes time. Some features take more time than others, and some features can easily be done in stages, as in: a simpler version at first, and a more advanced version later.

"Why not just fully implement every feature right at the beginning?" you might ask. The problem is largely a matter of time, and of priorities. There is a finite amount of time. Time to work on something, time to market, etc. A decision has to be made: how long will it take to fully implement EVERY desired feature? Is every feature even WORTH developing fully? This is one of the reasons you see applications released with simple, and often what I'll even say is incomplete, feature sets. Releasing an application, especially, a version 1, with simple versions of some functionality is often done precisely to solicit feedback, and to essentially allow users to "vote" on the features they want to see expanded.

MacGourmet has a few good examples of this process: shopping lists were something that I wanted to get into the first version, but I wasn't sure exactly how people wanted to use them. I haven't personally been a big user of shopping lists in the past (this will change I'm sure), so this was kind of a grey area in the design for me. After the first beta of version 1 was released, people were really good about saying what they liked and didn't like about shopping lists, giving me ideas about how to make them better in a future release. So, instead of spending a lot of time designing this piece the wrong way, and extending the overall development time of the application and release date in the process, a simple version is included, and feedback is received on that version. Later, a better implementation will be rolled out, but in the intervening time, the application has been tested, purchased (hopefully) and a user base created, all justifying spending more and more time and effort on the application.

This also brings up another point: It's a better business decision to release a feature-incomplete product sooner, rather than a fully-developed and possibly undesired application later, or in some cases, never. Even a feature-incomplete product provides a lot of feedback, and some revenue, two things that allow an even better version of the product to be released later. If you spend too long trying to make everything perfect, you'll often never release a product at all, or you'll release a very advanced product that isn't what a lot of people want.

One last point. Shipping a version 1 should not be an excuse for a shoddy release. Even if features haven't been as fully implemented as they might be later, maybe for the reasons described above, version 1 should still be tested as well as possible, it should be clean, and finally it should be stable. You still want to give a user a great initial experience.

So the next time you download an application that is version 1, after reading this you may understand a little better why "feature X" isn't there, or doesn't work "right." Chances are, all these features ARE there, at least in the head of the developer, or on their drawing board, and with feedback and registrations, you'll eventually get to see them.

0 Comments:

Post a Comment

<< Home