Yesterday I created a new Feedback item to stop the 90 Day Rapid Release Model. <feedback://showreport?report_id=14252>
In less than 24 hours it’s gone from the 4,000-ish rank to #11. Feel free to make it one of your priorities and let your voice be heard. If the Feedback system is truly the way to get things to change then this is our opportunity to test it.
I think we’re all fed up with half-baked and incomplete new features. Lack of documentation and examples aren’t helping us either. It’s to the point where each new release brings it own new set of problems. Each release causes anxiety rather than anticipation.
It makes using REAL Studio a pain. During the 2010 Release 3 cycle, the huge memory leak issue in Windows was causing me to revert back to Release 2 which also had its share of issues in Windows. I seriously debated if I had to go back to Release 1 or even earlier. Thankfully, RS decided to do a dot release for R 3.1 and subsequently R 3.2 but testing those two releases kept me from testing R4.
To be honest, I’m not opposed to the 90 day release cycle per se. I have a huge objection to the way it’s currently handled.
There doesn’t seem to be much planning going in to each release. It seems that the RS engineers are told to develop something new. They start development in *that* cycle and it gets added and released in *that* cycle. This leads to a lack of examples, lack of documentation, and features that are half thought out with too many outright bugs.
Here’s an idea: Anything added to the project *must* have an example project that exercises major functionality. Ideally it would tweak all properties to ensure proper functionality. This does several things:
1) Ensures that the feature works as it was intended by the RS engineer
2) Gives the RS internal QA staff and management something to verify before it’s released
3) Gives beta testers a reasonable example to start from. It becomes the de-facto baseline project for the RS engineers
4) The project becomes part of the official release and gives end users an example to use and learn from even if documentation is missing and/or incomplete
Let’s face an inconvenient truth here, shall we? The 90 day cycle is too fast for PROFESSIONAL users. There’s a reason why no other development tool uses that fast of a cycle.
RS needs to properly plan features out. They are in the R5 release cycle now so any new features not already added for beta testing can NOT be added until the 2011 R1 release. This also means that any major bugs found in a R5 feature be pulled from this release.
I don’t know if this can be done given current engineering leadership and personnel. If certainly feels that the current release and feature schedule is *marketing* and *sales* driven and that quality is not “job 1”.
Personally, I’d be happier giving my money to RS knowing that each release is as solid as they can possibly make it. I’m okay if that means that a release takes a mere 60 days or takes 180 days. A solid release means more to me than incomplete new features. Circling a date on the calendar as a drop-dead date is fine every now and then but it shouldn’t be an every release occurrence.
Some have asked why me, of all people, is forcing this discussion. The answer is simple. I use the product all day long, six days a week. I really, really like it – it’s the only product I’ve found that’s quite like it. It puts a roof over my head. It’s a good product now but it has such great and awesome potential. However, each release brings new problems and new pain. I’m getting old enough to know that I need to stop banging my head up against a wall.
I either effect change or move on. This is my attempt at changing RS for the better. Maybe they will and maybe they won’t. At least I can say I tried and I’ll have no regrets either way.