Product release cycles

DeeEmm posted 3rd of March 2010 in Community Voice. 14 comments.

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?


Did the release fail to deliver?


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


Please login to post a comment.
I agreed with what you said on that thread - a release every two to three months seems about right.
Two to three months is probably a manageable time-frame. My guess is that the biggest issue for Boonex would be resources, but this is simply reflected in the number of tickets / bugs / features that can be addressed in each release cycle.

Just noticed that AlexT has commented that in approximately a week all known defects will be fixed.

That's a big statement!

Hope he is right.
Don't hold your breath, we have been told things like this
Yes, this is my point exactly!

Expectations are held high, when they needn't be. it's the same thing all over again... and again... and again...

Everyone knows that the bugs will be fixed, that the coders are good at what they do, and the product is in essence a good one - or none of us would be here. The release and the bux fixes are pretty much a given - it's just how they are handled that need to be addressed.

If Boonex, address these kind of issues, they could be number 1 instead of see more number 2/3/4 or wherever they currently fit.

Google for Boonex Dolphin and mostly what you will get are pages of bad reviews:-

"A quick overview and a couple of reasons why not to use Dolphin."
"Why Boonex is a scam?"
"Boonex Dolphin PHP script is SCAM! Beware!"
"Boonex Dolphin PHP script is SCAM!"

And all this on page 2 of the search results!!


it's simple - poor public relations + poor project management.
That has already changed to "the end of March - maybe". Anyone here been around long enough to remember the "couple of weeks" estimate for D7 that was off by more than a year? I think they should just release what they have fixed every two to three months -we would all be able to keep up with it then, and we would all be on the same page.
Boonex should fix target to developers/testers
Dev/Testers should fix Min 100tickets/month
and Boonex should have a quarterly updates
Updates/bug fixes - quarterly
Critical updates - as an when required
feature upgrades - Bi-Annually
thats more than enough...I guess...

also i feel like we should have some external reviewers for the actions above.
External meaning - Non-Boonex Staff
like HS,Ct,Md,mc etc
lots of good things may happen when the releases are audited by professionals
What escapes me is an answer to the question, "Why do those bugs take so damned long to fix?". I am not a newcomer to CMS frameworks (six custom CMSes in private use and two multi-module CMSes in global distribution), and have myself chipped away bugs at a rate of 10-30 per day without too much headache.

If the bug issues arise from bad architecture that needs to be constantly revised (as the case seems to be as it's taking a small forever for what appear to be minor issues in the tickets), see more perhaps it'd be a wiser medium term call to try to just get the most critical of them out of the way, and then focus development efforts on a new, fresh framework that doesn't bear the weight of old and outdated code.
What escapes me is an answer to the question, "Why do those bugs take so damned long to fix?". I am not a newcomer to CMS frameworks (six custom CMSes in private use and two all-purpose multi-module CMSes in global use and distribution), and have myself chipped away bugs at a rate of 10-30 per day without too much headache.

If the bug issues arise from bad architecture that needs to be constantly revised (as the case seems to be as it's taking a small forever for what appear to be minor see more issues in the tickets), perhaps it'd be a wiser medium term call to try to just get the most critical of them out of the way, and then focus development efforts on a new, fresh framework that doesn't bear the weight of old and outdated code.
Damn these double posts! The comment box should be cleared after posting, pretty please, as it's easy to accidentally double post when you return to edit and have two identical boxes with the same content on the screen.
I agree - I think that the 'framework' is one of the issues with the time it takes - there is not really a defined framework for dolphin - it seems to be a little better with version 7 (to me it seems that most of the changes with D7 were not feature changes but simply re-writing existing code to follow a more structured architecture - lots of variable / database renaming and moving of files and functions) but there are still plenty of things that are 'tacked on'.

IMO a bad framework becomes see more even harder to manage when there are multiple contributors, as unless you are working on stuff you wrote yourself, at least half the time is spent trying to figure out what the previous softy has done. There is also a distinct lack of comments in Dolphin - comments help save time when looking through code - they are not necessarily just an explanation for lesser mortals - it probably takes less than a second to read and digest a comment, whereas it takes a lot longer to read and digest a line (or more) of code - all those seconds eventually add up.

I also find that there is a lot of spaghetti in the code, which does not help matters. Spaghetti logic is a term in my industry for unnecessarily, over complicated, too-many-layer, code. It used to be an intentional thing to obfuscate code, and therefore generally only be understandable by the original softy, hence making them a veritable coding hero and always ensure them of the job. But it is also a style of coding that is associated with those who don't know what they are doing - bit's tacked on to other bits tacked on to other bits...

An extreme example - 'function A' receives a value, processes it, and returns another value, only issue is, that the value returned is slightly incorrect, so the softy writes another function to overcome this issue - the incorrect value is then passed to 'function B' which returns it's value, which is unfortunately also incorrect, not perturbed, the softy writes another function to deal with this... Somewhere around about 'function K', the correct value is returned. And everyone is (blissfully see more unaware, but) happy - except for the next engineer to look at the job! (which in this case was me - a true example)

I am still amazed that in D7 there are includes, within included files that are themselves included in other files, that are themselves called within class files - jeesh (sound familiar - lol - bit's tacked on to other bits tacked on to other bits...).

Whatever the reason, it's not good code practice, and as Code Satori mentions - "focus development efforts on a new, fresh framework that doesn't bear the weight of old and outdated code." seems like sound advice. You've obviously started to do this with D7, but IMO the philosophy behind the code is still flawed and has some way to go.

With a decent framework / standard it's easy as you instinctively know how something should function - the framework sets the rules for how things should be written - especially in regards to things like reusable code and scope.

D8 (Trident) promises to be better in this regards, (is being described as a framework) - but if the realization of what a true framework really is / consists of, has only come into play with D7, then I'm afraid that D8 will have all of the same inherent issues as we have seen with D6 and D7, as it has already been in development for a lot longer.

...just some food to provoke conversation. ;)

If I have not got it all wrong.. They are making Dolphin with their CMS that is under development also.
I don't know what framework is used though.. Their own php framework?
With framework, I think of a php framework. And a cms is the gui - to make stuff like dolphin pages with a mouse and half a keyboard.
Some php frameworks are emerging from "beta", like Flow3 (with the cms Typo3 optionally used on top).
Anyone know if they make all of these?

If it is the case, that all in the see more same time they are developing - framework, cms, apps/scripts..
I guess they have a lot of code to view for most bugs and changes.

As for release cycle,
I guess released more often - with upgrade scripts - there would be a large increase in support questions also.
(something went whops during my upgrade, what happened to.. etc..)

I'd be happy to see a focus on frequent security patches (many touching the "function A -> function K" includings probably).
(have you checked your logs from 6.1.4 - 6.1.6..? here they still try to include c99 shells 10 times a day on the current D7 - search ".txt?"..)

Also a listing by area. Like chat fixes, privacy fixes etc..
I would then only pick the updates we need, and avoid the rest until "stable".
I am moving to dolphin from a site with about 3000 known bugs.. So I for one was very happy with the release of D7. :D

Also, very good point in the first post, about a team working together on 8 bugs in symphony rather than 100 in a clash.
Many of the bugs listed do not bother me at all, or are simple fixes or feature requests.
Perhaps having one list for the important (voted?) ones - say 8 core bugs - and have main team working closer together on them.
And sending bug reports to a maintainer, that reviews and adds bugs in a fixed way. instead of reclassifying and briefly changing comments etc..

Im anyway optimistic on D7, but ask me again at the end of the year :)

see moreYes indeed DeeEmm, those layers also trouble me, all those countless micro-functions that refer to other functions, and on and on in an endless continuum. You could just have one genre of functions in one class, one place and one file (or split for lighter dependency management), and that would make both bug-fixing and extension development a heck of a lot faster. That's the general architecture approach I aim for with whatever I code beyond single-file scripts, and so far I've been a happy camper.
Well said DeeEmm. I suspect this would likely speed up the development of Dolphin expediently as well.
Below is the legacy version of the Boonex site, maintained for Dolphin.Pro 7.x support.
The new Dolphin solution is powered by UNA Community Management System.