The *business* of software
How often should you put out new versions of your software?
This topic is one that I am currently puzzling over and I would love to hear what other people do and why they do it.
We have switched between doing as few as 2 and as many as 5 major releases per year and we sometimes need to do point releases or "hot fixes" in order to deal with high priority fixes.
It is really cool to be able to get some new features into the marketplace very quickly but there are trade offs such as putting too much pressure on developers leading to burn out and some clients get frustrated with multiple releases in a single year.
We are financially sound and weathering the current economic situation so we do not need to make "X" number of releases in order to survive.
Our application is implemented in ASP.Net.
We offer the option for clients to host the solution or have us do the hosting and our software comes with its own database. So when a new release comes out, we need to not only ship out the new application files but also provide a utility to rev the database so there is a set amount of overhead (mainly, testing and verification that the database upgrader is as bullet proof as we can make it) that is incurred whenever a new release is put out.
We have switched between doing as few as 2 and as many as 5 major releases per year and we sometimes need to do point releases or "hot fixes" in order to deal with high priority fixes.
It is really cool to be able to get some new features into the marketplace very quickly but there are trade offs such as putting too much pressure on developers leading to burn out and some clients get frustrated with multiple releases in a single year.
We are financially sound and weathering the current economic situation so we do not need to make "X" number of releases in order to survive.
Our application is implemented in ASP.Net.
We offer the option for clients to host the solution or have us do the hosting and our software comes with its own database. So when a new release comes out, we need to not only ship out the new application files but also provide a utility to rev the database so there is a set amount of overhead (mainly, testing and verification that the database upgrader is as bullet proof as we can make it) that is incurred whenever a new release is put out.
Replies to This Discussion
-
Permalink Reply by Bill Horvath on -
One of my (very wise) employees has said various astute things about this problem. Unfortunately I can't claim these observations as my own:
- Given a limited number of developers, you can specify a release date, or a feature set for a release, but trying to do both will likely get you in trouble.
- Customers like known release dates, even more so than knowing what features to expect on those release dates.
-
Permalink Reply by mark stephens on -
Could you have a daily build version as the beta which customers can download and then have a major release when there is something worth releasing? Then you could satisfy both interest groups.
-
Permalink Reply by Lou Immendorf on -
mark stephens said:Could you have a daily build version as the beta which customers can download and then have a major release when there is something worth releasing? Then you could satisfy both interest groups.
The answer to that question is yes and no.
Let me explain more about our application and our client base ... keep in mind that this comes from my perspective so I might be looking at this issue in the wrong way, suffering from tunnel vision or just a lack of imagination.
Our application is very broad based like a CRM application in many ways. I know from other discussions that applications like ours are dead and more targeted applications are the way to go (trying to be funny here) ... but humor me for a little while ...
We focus on helping people organize their marketing efforts and marketing covers a great number of feature sets so we provide project management, buying/selling media, file management ... a great number of things (full list is available on our website ... www.marketingpilot.com).
Our existing client base is very interested in have the application be very stable unless the change is something that they are really interested in getting. Our new clients want all of the latest and greatest stuff since some of these new features are important/critical to how they do business and also may have also played a major role in their purchasing decision.
So far, We have tried to please the clients by providing predictable schedules so new clients know when new features will be available and provide a clear upgrade path for our existing clients.
Keep in mind that there is a fixed cost for each major release (rev'ing online help files, quality checks, verifying all supported browsers, building the database upgrade utility, training support).
I am not sure how I could provide a rapid release model, balance these fixed costs and keep everyone happy/productive/sane.
-
Permalink Reply by Jason Glover on -
As fast as you can, with a couple of caveats:
1. That you don't move people's cheese around too much.
2. That you give users a decent "lead time" before a new release.
3. That you not change too much in any one release.
4. That anything you add that is drastically different from how thing used to be is an optional change that the user can opt in or out of (like Google labs features).
and finally
5. Only as fast as your current development processes can sustainably allow.
No 5 is my professional level of expertise and I make a fairly good living as a software process improvement consultant - however everything I do to improve each software dev shop could have been done in-house if they'd just bought Joel Spolsky's book and read it. :p
Badge
© 2010 Created by Neil Davidson.
Powered by 
.
