It’s Not About the Release Schedule

There’s been a lot of chatter about my recent blog posts.  I am not really opposed to the 90 day release cycle – that’s not the problem (and as such the feedback request is poorly titled).  The real problem is the quality of the releases that happen every 90 days.

Each release cycle brings many bug fixes and that’s great, but it also introduces new bugs and changes in functionality.  This happens for new features and for other changes (including refactoring that’s going on for Cocoa).

I realize that there will always be bugs.  It’s next to impossible to ship a product that’s perfect – especially something as big as REAL Studio (that spans three and soon to be, hopefully, four platforms).  But, reporting easy-to-find bugs after the release gives the product an unnecessary black eye.

Part of the problem, I feel, is the beta program.  The mantra has been to test your projects with the beta build and ‘test everything’.  Since my time is valuable, that’s akin to saying “test nothing” because, like REAL Studio itself, my projects are rather large.  It either compiles or it doesn’t and that’s not testing the product, that’s smoke testing (electrical components work on smoke and if you let the smoke out of the component it fails – sorry, electrical engineering joke there).

No one tells the beta program to test “x” feature – we just get a list of bug fixes.  I know I would like something specific to test to get the most out of my time.  Harness the people that have already volunteered their time and effort!

The Feedback system has a lot of bugs and feature requests.  Many of them are very old (they predate this incarnation of feedback system).  Some of them should be closed and some need to be addressed.  Should feedback items older than 6 months get an automatic system vote and then get another vote every 6 months thereafter?  That fact that there are a lot of open bugs is worrisome.  Should bugs and feature requests get the same level of weighting?  Should they have separate areas so that priorities for feature requests are different than those for bugs?

As someone who has spent considerable amount of time and effort trying to reduce Windows flickering I feel I can say that Windows builds right now have some “issues”.  You can say anything you want about the individual controls, I think the issue is with the Window itself.  Put a background image into a window and you might as well put sunglasses on to avoid a headache.  I bring this up because you don’t see this issue in Mac OS X (because the OS double-buffers the window).

Does REAL Software need to spend more time using Studio in Windows?  I dunno, but Windows is not like Mac OS X.  There is quite a bit of inconsistency between platforms.  Some of that is the OS and some of it is REALbasic.  I’m not enough of a Windows expert to offer any hints, but I do know that if I run into problems it will inevitably be on the Windows side (see blog posts on memory leak issues).

I know some people are pretty upset with the new LLVM compiler for RBScript.  It doesn’t work for many causing them to stay with an old version of Studio.  The problem is that the beta program said it was broken and it was released anyway.  Again, I realize that you can’t fix 100% of the bugs before release but when the major users of RBScript are saying it doesn’t work – perhaps it should have been delayed.  Maybe there should have been an option to use the old compiler.  I have no idea how much work that would have been but it would have resulted in more testing and a happier bunch of RBScript users.

So rather than focusing on the 90 day release cycle, let’s focus on the root causes of our unhappiness.

These are just a few of my thoughts.  What do you think?  Did I miss anything major?