Development and Release Processes - Part IV

[vB.Org System]

So ... by now most of you have had a chance to interact with Jira, our issues tracking system. Jira is not only used for issues tracking - it is also our project management tool. Everything and anything we are working on or will be working on is in Jira. If there is no Jira entry then it does not exist. Jira entries, in many cases, also contain the specs and if they don't, they will soon. At the end of the day, and for the most part, you all can see what we are working on. We are still working out how to be more communicative, especially for those of you that prefer not to use Jira. But again ... it is all there.

Also by now, you all have seen and experienced the fact that we are doing fast iterations and delivering those to you as soon as they are ready. I am a little frustrated that we are not going faster, but quality is our primary concern. Thus, our speed is dictated by our quality. New features will require longer cycles. Still, we are dying to deliver more and better releases.

When we changed our development process we did it in favor of being more flexible. I wanted to be able to wake up any morning and decide that I wanted to release bug a, b and c, enhancement d, e and feature f, g and h. Since everything is developed in individual branches - well, not exactly, it is more complex than that, but that will be covered in a future post - we have a great deal of flexibility in how we are able to decide what and when to release. Furthermore, since we do continuous integration and nightly builds, we are also continuously testing each build.

Not only do I like this approach, but it has been working well for us - as it did in the past for me as well. And over time, it is going to work even better. There are some inherent drawbacks with this approach, one being that release denominations go out the window. With smaller incremental releases that have bug fixes, enhancements and features, some of the "wow factor" is lost, as well as some clarity in terms of expectations.

The traditional expectations around release denominations is that major "enhancements" to a product - either by adding new features, majorly enhancing or even reworking existing features - are denoted by a change in the version number. An example is vB2 to vB3. Another example is Windows Vista to Windows 7 (not a number change, but a major denomination change.) From a product point of view, these releases should bring a big WOW which is the intention.

Similarly, major revision number changes - i.e.: 4.0 to 4.1 to 4.2, etc. - are expected to represent major milestones in the development of a product's roadmap. And minor revision number changes - i. e.: 4.0.4, 4.0.5, etc. - represent the release of lesser enhancements and bug fixes.

vBulletin followed this model, which is very much attached to a waterfall project management and development methodology. But on a more "agile" form of managing and developing a product roadmap, the model starts to make less sense. Especially if you are eager to release to customers the latest and greatest; and especially if the product showcases some challenges. Even more so since the development process has accelerated getting work done.

So ... what's a customer to expect in this crazy new way vBulletin is being managed?

A major revision number represents the conclusion of a release cycle. In the case of 4.1 for example, 4.0.7, 4.0.8 and 4.0.9, as well as 4.1, all represent the road to 4.1. Thus, 4.1.1, 4.1.2 and so on, concluding with 4.2, are all parts of 4.2. To explain it differently:

1. A major revision is the sum of the previous minor ones
2. We will continue to produce quality releases as often as possible
3. Customers can upgrade whenever they feel comfortable with the progress achieved and available features and enhancements

In re-reading some of the comments from my previous posts, I think (3) is the most problematic of these three points. Customers should not feel pressured to upgrade every time we put out a release.

Let me present the case in a different way: We could produce the same releases as we do now but not make them available at all and, once a quarter, release whatever we accomplished and call it 4.x. This approach does not work at multiple levels. For starters, it shortchanges customers; software will always have bugs and while we strive to be bug-free, that is just not 100% possible and this approach provides continuous relief for old and new bugs.

Second, it removes the ability for customers to decide when to upgrade. In the new way you can upgrade every time or once a quarter or once a year; thus providing more granularity in deciding when to upgrade.

Furthermore, the once-a-quarter approach might work if we wanted to be tight-lipped about what was included; however, while some Jira entries are private and not readable by everybody, we have adopted a policy of transparency.

Still, point (3) remains a concern. The only way (3) will no longer be a concern is if we communicate better what is in each release, including potential areas of risk and shortcomings. The good news: we are already doing this and with each release the quality, not only of the code, but also in the area of communication is improving.


Finally, I would like to take the opportunity that these posts present and thank you all for your feedback. I find your feedback very valuable.

Thank you.


More...