- May
- 05
- 2008
There Is No Version 1
By: Robert Dempsey | Tags:
Is there some magic in a version number that I don’t know about? There must be, since so many applications use version numbers. I was thinking about this as I was adding tickets to the project from which What’s up in Ruby sprang, and mindlessly creating versions and putting tickets under each.
What constitutes a version? Is it a certain number of bug fixes or features? Perhaps a combination of both?
It struck me that in the web development world we don’t put version numbers on our apps, at least not externally. Last week we offered this set of features, and this week we have these new features. Great! But mommy always said it is good to have goals, so what are we to do?
First, stop labeling anything “beta” or “alpha” or “version 1.” There’s either something out there, or there isn’t. It might be available to a select few, but it’s out there.
Second, implement scrum. Put all of your tickets into a backlog and prioritize them. Plan what you will do for a sprint (10 working business days for us), do it, and then deploy it. At the end of that sprint you should have potentially shippable product. If you need more time extend the sprint. Be flexible with what a sprint means to you, as long as it isn’t longer than a month.
Don’t make your users wait for new features. If they work, put them out there. Get feedback quickly and respond accordingly. Software is continuously evolving. Let that evolution happen incrementally rather that in giant leaps. Involve your users in the process and you will reap the reward: happy users.
Share this post
Other posts you may enjoy
You can leave a response, or trackback from your own site.
7 Responses to “There Is No Version 1”
On May 5th, 2008 at 8:04 am Jonathan Nelson said:
i completely agree with your post Robert. i’ve always wondered why we use versioning when trying to associate new features. i honestly think its just a way to extend the inevitable and try to elbow for some more time. people here use it as an excuse not get stuff out the door….an excuse to be lazy, in my opinion.
On May 5th, 2008 at 8:23 am Anthony said:
There are big changes and there are little changes. Traditionally version numbering helped identify the effect of changes. Major version number changes indicate backwards incompatibility, minor version numbers were for significant enhancements that were backwards-compatible and tiny version numbers were for bugfix releases and small enhancement releases. Does this apply to the web? Probably not so much given that users don’t control the upgrade process.
On May 6th, 2008 at 1:22 am Taryn East said:
Hi robert. For many years I’d have agreed with you - but the last few months our client hammered home why this aint necessarily so (at least in certain circumstances).
If the website you’re delivering is all yours to play with - then I’d agree 100%, get it out there and earning valuable feedback. The opportunity cost of lost feedback is purely to your detriment.
But if you’re working on somebody else’s website, then it may or may not be the best option.
In our case, the client is paying for real, live testers to check that it’s still doing what it should be. This despite all the automatic tests we have on our end. We can’t boast perfect code-coverage, but I’m pretty determined to cover all reasonable circumstances in our tests. Still - they insist on external, independant testers to double-check… and it’s their business so they call the shots there.
Now, those testers cost money to check the system every time we deploy. So we have to run that cost against the opportunity-cost of putting out frequent fixes.
As usual, in a system with conflicting requirements, there must be a balance. In this case it’s between “getting code out there” and “having to pay those testers again us to test the same stuff”.
Internally we run agile - but we save up a whole bunch of changes and roll them into numbered versions for the testers. They can then lodge bugs aginst the versions - and we can deploy them when the bugs are reduced to client-acceptible levels.
Call it half-agile perhaps
Note: this doesn’t detract from your point - just an example of a possible exception
On May 6th, 2008 at 6:18 am Robert Dempsey said:
Taryn,
Thank you for adding your experience to this post. It is this kind of feedback that is exactly what we are hoping for.
On May 6th, 2008 at 1:37 pm Paul Klipp said:
I find version numbers useful, as long as the system is clear to everyone involved in the project. We use a system easily defined as: x.y.z where x is major releases, y is planned updates and z is unplanned updates. The existence of version numbers and the fact that we automatically append the version number to user comments and bug reports is very helpful in identifying and fixing issues.
On May 6th, 2008 at 6:14 pm Richard Banks said:
Robert, generally I agree, though versioing is useful when you’re doing apps where not all customers are running the same version (think desktop apps, etc) and the beta tag can be useful to communicate to your customers that you’re still working away like crazy to improve things so expect stuff to change.
Secondly, you said “If you need more time extend the sprint”. You don’t do this if you’re using Scrum. You want to timebox an iteration and always stick to it. If you can’t get it all done then talk to your product owner and remove a feature, delivering a little less than you planned.
On May 6th, 2008 at 6:27 pm Robert Dempsey said:
@Paul Klipp: do you use your version number system for web applications? Does it make a difference to your users?
@Richard Banks: I agree that versioning is absolutely necessary for desktop applications. I also agree with you on not extending a sprint when using Scrum. I should have phrased it better - thank you for pointing that out.