I’m always puzzled by how hard software can be to write the first version of any software product. Software in itself is always hard, for more reasons than I can write in a blog entry. But what makes Version 1.0 so hard? I’ll give you a hint, most of it has nothing to do with your developers. It has more to do with the process of innovation.
The reality is that most things that are version 1.0 are usually not built correctly. But with software, you truly feel the pain when it’s built wrong. Instantly. Other examples would be new models of vehicles. They usually always have massive recalls. Where there is innovation, there is usually a bug (or several thousand). There is no way around it. As much as you may test the software package for months, years, and longer, with your quality team, there is no replacing real life testing.
In some cases you may ship great 1.0 software, but is the software shipping on time?
Version 1.0 Software Means Innovation
If you are writing 1.0 software, you are creating something that has never been done before. You are innovating! This is was makes software the best industry to be in (I think). If it is something that has been done before, stop reading this article, go buy the product that already did it, and use that. Customize it, and feel happy that someone else has gone through the pain of 1.0. If your thinking, well there is something else out there, but I don’t like it, well then, you are still in the Innovation phase, and you will still be climbing Everest because someone else failed at building software that you feel is awesome. You will be innovating!
Version 1.0 Software Means Trial and Error
As much as every other developer or company that comes to visit your office tells you "If we use AGILE/CMMI/[fill in methodology of the week here] we will deliver on time what you want.", don’t believe them. While this is true in a sense, I akin this to the reality of getting that car you want at the price you agree to before signing all the fine print that nobody ever reads from front to back.
The problem is that while all these methodologies are great, there is simply no way to give a date to when software will be ready. Did Thomas Edison give a date to when he would discover the light bulb? Did the Wright Brothers tell the world the date they would build the first airplane? Yes I’m exaggerating a bit here, but I hope you see my point. What is my point?
There is no way you can give a ship date on version 1.0 software.
I don’t care how much up front analysis you do, feature driven development, vision scopeing, etc you do. There is simply no way you can do this. Why? because at the end of the day, what is Version 1.0 software? What should it be?
Version 1.0 Software is software that works as the user expected it to work.
So let’s say you follow Agile for example, and you deliver new versions every week to your users. You do everything right, you work in small iterations, and keep building on top of the last version. You have totally scoped out each feature, each use case, each actor, etc. etc. You should be rocking right? Wrong. Why? Think about where you are getting your information from. Your users. Your user interface team and business analysts are thinking it through and deciding on how to provide the information to the software architects, to be given to the developers.
As development starts, and as new versions come out, users start realizing there are problems. Project stakeholders realize that, "Oh, that is terrible, that’s not what we want.", so things start to change, and there goes your project timeline. Sure you can tell your users, we will put that in version 1.1, or version 1.5 or whatever, but the reality is, if certain features are left out that are needed, and if things don’t function the way that you want them to, are you really delivering the 1.0 software that works like the users expected it to work? Will the users be thrilled? Probably not.
In Closing
Version 1.0 software is all about dreaming! It’s about creating something that has never been created before! It’s about having fun, innovating new methods and process’s. It’s about setting goals for yourself, and trying to surpass them. Unfortunately, as in life, sometimes you may meet your target date, sometimes you will be late, and sometimes you may be early. Even if you lay out the best plans, you can’t control the independent variables. That is what makes life so exciting, and that is what makes software so thrilling to create.