Product release cycles

There is an interesting conversation in the forums relating to the anticipated 7.0.1 bugfix release, to add a bit of background to this for those who do not frequent the forums, there are currently 169 closed tickets, with a further 51 still to go. Some are of the opinion that 7.0.1 should be released now, as there are many bugs that need addressing, whereas some are prepared to wait.

How long is long enough?

In my opinion, long release cycles have a habit of disappointing. The expectation is that the final product will be perfect, everything that everyone wants, it will meet all expectations, or even exceed them. The extended period of time also heightens this belief, the anticipation serves only to increase expectations.

With the expectation that the released product should be perfect, anything that delivers anything less than perfection is seen as a failure.

Are peoples expectations too high?

Yes.

Did the release fail to deliver?

Yes.

The time is actually the issue, not the code, or even the fact that it fails to deliver.

The best business model is short time between releases, that promise less than they deliver, that therefore exceed expectations (satisfaction > 100%)

Why have 100 tickets - that take a year to fix, and only release them when all are closed? - why not release 50 after 6 months? why not release 8/9 every month?

Here's a hypothesis:

Take the first case - in 1 years time there is a release with 100 fixes, but these have not been tested fully as fixing individual tickets is only half the answer - all of the individual fixes also need to be tested together - especially in an environment where there are multiple developers. Some files may have multiple edits for multiple bugs - the third programmer to edit the file, is unaware of edits 1 and 2 made previously by different programmers and unwittingly breaks a previous fix, so all edits need to be tested together - This is an exponential amount of work!!!

So the release invariably has a few unnoticed bugs - These are mostly small, but there maybe one or two larger, more annoying ones - perhaps a security related issue or a usability issue. Now you have a LOT of unhappy people, especially when you consider that, not only have they had to wait a year, but going on past experience, they they will not get the update to fix the issue for another year.

So the developer decides to release an interim fix, but this takes resources away from the core development, so this suffers, which has a knock on effect on the next planned release, pushing the release date out further, perpetuating the anticipation > disappointment cycle. This cycle is also made worse by the fact that despite many suggestions by the end users, for specific fixes to be released, none are.

Second case - same thing but this happens six months earlier - the anticipation was not so high, users do not have to wait so long for a solution. The first 50 bugfixes will also have 6 months worth of real world testing by the time the next 50 are released - a very valuable thing, and reason enough not to wait a whole year. This solution is ultimately better, but in the web industry, 6 months is a long long time.

The third case, has a release every month, equating to some 8-10 fixes. Testing these fixes together is nowhere near as much work as trying to test 100 fixes, written by different people, using the same files. Any residual errors are minor, and with the monthly release cycle, are addressed quickly. If a big big error happens to creep into a release, the release cycle is not changed - a patch is simply released to temporarily address the issue until the next release, The real world testing is also a more gradual process, meaning that it is easier to diagnose any residual errors. but perhaps even more important, the anticipation > disappointment cycle is practically non- existent.

Whilst Increasing the frequency of the releases is more work - the more frequent the release, the less testing is required - testing a release of this magnitude can also be handled quite easily by beta testers and one reviewer working part time, whereas the yearly release is massive undertaking requiring a lot more dedicated resources.

With more frequent releases, everyone working on developing, soon gets used to the release cycle and develop systems of work that suit it. Also from a management perspective, determining what releases will contain is also a job made easier. Instead of having to work out how long 100 tickets will take to address, the developer only has to determine how many tickets they can address in one month. If a  ticket doesn't get fixed in time - it simply rolls over to the next month - waiting an extra month for one ticket is nowhere near as bad as waiting an extra week for 100! From experience, initially, developer estimates will be high, but eventually things will settle down and tickets promised will be delivered.

A monthly release cycle also allows some prioritization of how fixes are handled, and perhaps best of all, also allows fixes to be reactive to the end users suggestions, so those fixes that the users see as more important, can be prioritised to be dealt with first, thus helping keep them happy.

Of course - prioritising a 'want' / 'nice-to-have' over a security fix is an ethical decision that management will need to take if the situation arises, but by guess is that the community would be a happier more content one, and best of all, reputation points will be high, and the product will be a lot more stable.

...Some food for thought

/DM