Quality Either Matters or it Doesn’t

My Saturday was supposed to be dedicated to a training video for the new Segmented Control introduced in REAL Studio 2010 Release 4 that was release this week.  Unfortunately, I stopped after about an hour after documenting bugs and becoming generally disgusted with it.  What’s the point of doing a training video for something that is THAT jacked up and must be fixed (to be really usable) in a future release of REAL Studio?  Why waste my time doing a video that I’ll have to do again?

I think it’s awesome that REAL Software creates REAL Studio and a handful of other projects using REAL Studio.  But they don’t use it like we do in two different ways:  Their testing process (and I wonder if they really have one sometimes) does not test the way a real world user creates projects.  Their usage of RB for the IDE isn’t a real world example of what anyone is trying to use RB for.  Saying “we build REAL Studio with REAL Studio” isn’t a valid metric for anyone except REAL Software.

I’m not an average REAL Studio user – I get that – I actually make my living off the product.  I use it eight to ten hours a day on average of six days a week.  When I do my testing, I start by creating a simple demonstration project showing the most basic usage of ‘X’ and then expand upon it by exercising most of the properties, methods and events.  Most of these demonstration projects end up being reused in real world consulting projects and in the twenty-plus hours of training videos I have on my website.

I rarely waste my time and, in my opinion, the new features in REAL Studio 2010 Release 4 was a complete waste of my time.  The documentation was late and incomplete and the new features have glaring bugs in them.  If I can document several in an hour what does that tell you?  Where were the example projects demonstrating the new features for Release 4?  There were none.

Have you ever perused the Examples folder?  There are a lot of example projects showing you how to use individual parts of the REALbasic framework.  Depending upon which release you look at, some of the examples don’t even compile.

I also think it fair to say that most of the examples (that are working) are watered down to the point where they only show the most basic usage of a component.  They are not complex examples and therefore don’t do most people much good when they get around to implementing it in their own projects.  Most are not written with best practices in mind or how average people will use them.  They were written with the intent of getting if off the developers, or documenters, plate as quickly as possible.  Comments?  Naming conventions?  Defensive coding?  Good luck.

REAL Software as a company does not create new cross-platform applications using their own product.  They don’t see the day-to-day deficiencies that we do.  They don’t feel my pain and that’s a problem because they’re trying to sell their product to people just like me – or at least that’s what they keep telling me.

I’m about ready to stop using REAL Studio for certain types of projects because they’ve lost control of the quality.  Quality either matters or it does not.  Decide which and let me know – I have better things to do until then.

Here’s my unsolicited advice for REAL Software:  For every new release build a new project that demonstrates EVERY new feature and exercises it.  Major changes to the framework get the same treatment.  These projects should be good enough so that if there is missing documentation, the code tips or autocomplete doesn’t work (all real world examples, by the way), anyone can still figure it out from the code.  It takes planning and a commitment and thinking about how real users will use the feature in Windows, Linux, Carbon and Cocoa applications.

Please, do this for upcoming Cocoa and Web Edition releases.  If you could do that, I’d guarantee you’d find more bugs, earlier, and I wouldn’t have to spend my Saturday writing an opinion piece.

What are your thoughts?

50 thoughts on “Quality Either Matters or it Doesn’t

  1. In all fairness we do in fact use the product in much the same way you do. We create REAL Studio, which is a a HUGE project that is probably larger and more complex than 99% of the projects that are made with REAL Studio. We also create Feedback, Lingua and REAL Orders (our internal ecommerce system) with REAL Studio as well.

    Now you can argue that these apps are not like your apps but that’s going to be true of any apps you compare. REAL Studio is a general development tool so lots and lots of different kinds of apps are built with it.

    Certainly testing helps to find bugs. There’s no question about that. However, even testing with example projects won’t always find bugs. That doesn’t mean we shouldn’t do this and in fact we do.

    Regarding Web Edition, the example projects are designed as you describe. They both demonstrate a feature and explain how it works.

  2. If we are to be RS’s unpaid testers (I often feel that I’m paying to test) then why can’t RS publish their regression test suites*? Public scrutiny would help reveal the bald patches (e.g. RBScript in the last several releases) and deficiencies. Feedback would make such tests better.

    * assuming any such beasts exist.

  3. Well, I see they documented the SegmentControl already. For the outdated example projects, I can say that I have code here to batch compile over 1000 projects. This way I make sure my example project do compile. There is a feedback item related to this: 5365. And it would help to be able to compile with the command line. See feedback item 3215.

  4. You know Bob, your idea of having the engineers create example projects for new features is actually right on the money. For the most part they don’t do that now. Example projects are often created by others. Effective immediately, I’m requiring engineers to create an example project for each new feature they create. As you described, these examples should be sufficient to both exercise the new feature and teach a user how the new feature works. They won’t be able to pass a case for a new feature to testing without an attached example project. Good suggestion. Thanks for making it.

  5. Geoff Perlman :

    In all fairness we do in fact use the product in much the same way you do. We create REAL Studio, which is a a HUGE project that is probably larger and more complex than 99% of the projects that are made with REAL Studio. We also create Feedback, Lingua and REAL Orders (our internal ecommerce system) with REAL Studio as well.

    You’ve proved my point. That’s 4 applications that have been around for a while and are being updated on a semi-regular basis. I’ve created many more than 4 new projects, from scratch, in the past month.

    So where in those 4 products are you using the new Segmented Control? How about the new Prepared Statements? How about the Add/Remove Handler or the Subscript Operator?

  6. Christian Schmitz :

    Well, I see they documented the SegmentControl already.

    I disagree. When I search in their Wiki page for ‘segmented’ I get nothing except the ‘what’s new’ page. That’s not documented – that’s mentioning it in passing.

  7. Geoff Perlman :

    You know Bob, your idea of having the engineers create example projects for new features is actually right on the money. For the most part they don’t do that now.

    I don’t know what to say to that, Geoff. It seems odd that a software development company doesn’t create example projects demonstrating its own features….

  8. @Bob Keeney

    Obviously we do. But often the example projects aren’t created by the engineers as they are developing a new feature. They may create one to quickly test the new feature but that’s not the same as creating one for the purposes of showing others how the new feature works. That requires a lot more thought and a more thorough test which exactly why I think it’s a good idea.

  9. @Geoff

    Paul’s idea of Real Software publishing their regression test suites is also an excellent idea.

    I wish Real Software would go back to polishing a release until it’s ‘ready’ by releasing a bug release if something is found to be glaringly wrong.

    Releasing the regression test suites would go some way in ensuring a release is ready, releasing bug releases would guarantee there are decent versions of Real Software available to your clients.

    Regards

    Keith

  10. @Bob
    I just don’t have the words to express how much I totally agree with everything you’ve said.

    @Geoff
    – Nice that you’ll now make the engineers create example projects.
    – Pathetic that it’s taken you 12 yrs to realise that you really should ‘properly test’ your product.

    Why don’t YOU spend a couple of days developing ‘Real World’ program(s),
    then kick back, relax and think about the following….

    A quick scan of the forums would show;
    – Every release brings more new bugs than bug fixes.
    – Most new features released are buggy, usually to the point of being useless for a few more versions.
    – If you’ve written more than 1 program with RS, upgrading to a new version of RS is painful, and you’ll often find a “show stopper” that means you need to go back to a previous version anyway.

    Changing programming languages requires an investment in time to build a framework first.
    Generic error handling, general functions for this’n’that, etc etc
    – Would you be happy investing this time to use RealStudio?

    No programming language can do everything, so you’ll need to write/buy some addons.
    – What addons would you need and what would the time/cost be?

    So bearing all this in mind…
    – Would YOU buy RealStudio?

    and then from a CEO’s point of view…
    – Are 99.7% of our customers happy with RS?
    – What % that purchased RS are still subscribed..
    – Purchased 5 yrs ago?
    – Purchased 2 yrs ago?
    – Of these what % have been continously subscribed?
    – What is the $value of the “Missed” subscriptions?

    – So therfore, Is RS as successful as it could be?

  11. Some important phases of program development are described in this post and in its comments. Let me expand upon them and add some of my own:

    1. Unit testing all code. Regression tests can then be run on code changes. Code can then be refactored to meet the DRY rule (don’t repeat yourself) and make adding new features easier.

    2. Documenting all features completely, as the features are written, within the feature’s code. These comments and any changes to them must be dated. A master documentation editor would then ensure that the user documentation thoroughly reflects the internal documentation but is understandable to users. With each new release, the user documentation would be updated according to the dates of feature code modification. A “last modified” note would be added so users can check for changes. A “Change History” master page would list all of the changes per each release, but in this case sorted by feature and hyperlinked to the feature’s documentation page.

    3. Testing each new feature exhaustively in individual test projects and publishing the test projects for feedback on them by users (beta testers at the minimum).

    4. Writing an exhaustive large project that tests all features together to see if the controls work correctly beyond the small individual test programs. A section of this project should test control cooperation and interactions with appropriate library features. This, too, should be published for feedback on it by users (beta testers at the minimum).

    5. Ensuring, as much as possible, that those features are written in such a way that Extends, or external libraries, subclasses or plug-ins are not needed to bypass feature bugs or provide missing basic feature functionality — plug-ins could concentrate on adding lucrative special features needed by subsets of users rather than basic features needed by the entire REAL Studio user base. With new REAL Studio release, the priority should be fixing bugs in existing features, or expanding the usefulness of existing features. A lower priority should be place on adding brand-new features. Of course, I understand that Cocoa and Web support must be completed quickly, and the incorporation of Cocoa will allow many existing features (mostly controls) to expand their usefulness.

    6. Only if absolutely needed, new features and their expanded functionality could be added first to the platform which has native support for it (i.e., the easiest platform on which to implement them, for example at present the new abilities specific to Cocoa controls), with a caveat to the user in the release notes and the user documentation that for now these features are specific to that platform. A list of platform-specific features would be listed on a page of the user documentation. They would then be implemented for the other platforms to ensure cross-platform compatibility. Once they are added to other platforms, the users would be notified via release notes and documentation.

  12. I should add:

    7. Implementing Design by Contract: All features should begin with Required statements and end with Ensure statements to help ensure detection of flaws.

    8. Each feature should have built-in error detection and exceptions.

  13. Glad to see most of the comments are about RealSoftware moving forwards to fix the problem, rather than the usual moaning. Hopefully, since Geoff is reading these, something will be done.

    Full disclosure: I am still using 2010r2.1 for my big projects.

    The focus on bug fixing does appear (regardless of whether true or not) to have slowed down over the last year, and some of the ones that are not fixed are fairly fundamental for “advanced” users. Said users of course are capable of working round them, but it still adds development time.

    Web edition may well bring RS more income, and LLVM may simplify compilation issues, but are the other new feature byproducts of improved core code, or just new. For example, segmented control – fine that’s another custom canvas control I can drop, but how important was its introduction? Whereas I currently count 21 confirmed and not fixed memory leak errors in feedback.

    Currently, so far as I am concered so long as I stick to a version of RB, it still does the job more efficiently than the competition, but continuing to subscribe (or level of subscription) will depend on the quality of new versions. I don’t think I can add anything useful to what everyone else here has said about how to achieve that.

  14. The segmented control is actually a native control not a custom canvas.
    It was added as we’ve had requests for it and we have a need for it in our own work.

  15. @S-Copinger,

    I am really looking forward to full LLVM implementation. As Geoff has previously stated, the next step would be an improved linker that would allow unused framework code to be stripped from users’ programs, resulting in smaller programs. This would allow RB to not only be an easier alternative to Objective-C and C#, but it would create programs that aren’t much bigger than those written in Objective-C or C#.

    I’ve had to use C# on a recent consulting project, and I’ve slowly been relearning Objective-C/Cocoa for the iPhone (slowly not because Cocoa is that bad, but due to job requirements making me concentrate on other things instead). Still, I know that RB coding is faster and can be a lot of fun. Even when I don’t need a program to be cross-platform, I prefer to use it.

  16. Agree completely with your sentiments Bob.

    This past year of RB updates has forced me to look to transition my code away from RB to all web-based frameworks. The last part of my application that is in RB is a massive RBscript class. Given that RS’s recent updates to RealBasic have destroyed RBscript for my usage case, they are really forcing me to move away from them.

  17. Well, the LLVM change is a good thing on the long run. Currently they use it for RbScript. As far as I know they do have unit tests for RBScript and I expect the current RBScript Plugin passes them. The hard thing is to make such a compiler+framework rock solid. So Jack, please send some crash reports with example project into Feedback app.

    From the LLVM change I do not expect smaller apps. From the rb framework a typical application uses most parts. What do you expect to leave away? A few controls? Everything that can easily not linked in is already a Plugin like rbscript, QuickTime or Regex. Also if you want to use introspection and see all the methods, the linker can’t leave a few away…

    And for bugs, well I use for a project a certain REAL Studio version. And I keep that project to the version unless I really need a new feature or a bug fix. Moving a project to a new REAL Studio version is a project on itself and normally only part of the alpha stage. So we can test our app as long as possible with this version before we ship it. But this applies for all IDEs.

  18. @npalardy
    The Segmented Control may be native on Mac OS X, but I have never seen anything like this in a Windows application. It also look pretty awkward in Windows with hard-rounded corners. It is not possible to move focus to the buttons using the keyboard which could be a usability issue….
    Also I thought I read that the control was implemented using a canvas on non-Mac platforms, but maybe I am wrong there…

    The documentation is wrong, MacControlStyle describes the SelectionType function. (logged as FB 14245)

    Interesting to see platform-specific controls are creeping up in RB, really looking forward to have the RibbonUI control for Windows in a future version 😉

  19. My 2 € cent
    Microsoft released no less than SIX free service packs for VB6.
    However they had the luxury (so I’m told) of being happy to lose money on developer tools.

    Programmers are probably better at finding (or at least recognising) bugs in software than general software users are, who’ll often assume it must be something they’re doing wrong.

    Now if there is one group of buyers you’d expect that would be willing to pay for bug fixes it’s programmers. After all, we understand ( http://scripting.com/davenet/1995/09/03/wemakeshittysoftware.html ).

    Are programmers are more interested in paying to fix the faulty item they bought than anyone else?

    The fact that REAL feels compelled to maintain a mixture of new features and bug fixes in every release suggests otherwise.

  20. I agree with Bob. I have been using RS since mid-2009 (not a long time). In the past year I have seen enough problems introduced with each release, I don’t plan on renewing my subscription any time soon. It seems to me the rapid release concept is pretty much useless when each release just leads to more complaints. Why not do one release a year that has been tested, and tested, and tested… and is ready for use. I think more subscribers would be more willing to renew. Don’t take this as a hateful complaint, but as an opinion of a user wanting to move from .Net to cross-platform.

  21. Part of the reason why I got into the beta program (many years ago) was of ‘new features’ that were prominently featured in release notes that didn’t make it into the release. This is before Studio was made in Studio but some of those same issues apply here.

    I think another great reason to have the developers work up a full and comprehensive example is that it becomes the de-facto baseline for beta testers. If nothing else it will lead to *less* confusion in what a feature is supposed to do.

    I imagine that I will load the project, take a look at what the example is and then start modifying it to fit my own projects. If I find a bug I then send them the project back with specific comments. Since it was their project to begin with it should be easier to debug.

    I see it as a win-win-win scenario. RS wins because they have a well documented example. Beta testers win since we no longer have to guess at features (not to mention features/changes that don’t get prominence in the release notes). End-users win because they have an example that works. We all win because we are happier. 🙂

  22. denis crowther :
    – Every release brings more new bugs than bug fixes.

    Denis, I would disagree with this statement. To be fair, each release has many bug fixes – certainly more than new bugs. However, the sentiment that they *do* create bugs is well founded. New features, especially, seem to be buggy or half thought out. Of course, if the developers could do some example projects beforehand we might be able to solve that part of the problem during beta testing.

  23. Love the comments!

    The true definition of insanity is doing the same thing over and over again expecting a different result. If we don’t want the same results lets try something different. What do you have to lose that you aren’t losing already?

  24. @jharris
    I think users are divided into two categories: hobbyist programmers and professional programmers. In order to keep up the ranks of the former, RS needs to push out “cool new stuff” every couple of months to keep them interested and willing to pay the non-trivial new and upgrade fees.

    The pros, on the other hand, use the product on a daily basis, and use most of the features. They see the bugs, especially when they try and compile their giant projects. One new bug can make a release unusable for them (I haven’t been able to use any since 2010r2.1), and the ultra-short beta period leaves little time to do proper testing – either for the RS folk or the likes of us users.

    Ask any pro whether they’d prefer fewer bugs or more features, and I can guarantee the answer.

    So why do us pros upgrade? Usually because we want to use a feature that doesn’t work in the previous release (because of bugs), and more rarely because we lust after a new feature. Sure, I’d like to start moving from Carbon to Cocoa, but the current versions are completely useless for that, and we won’t even get started on the plugin problems.

    My suggestion is a 6-month release cycle, with at least 4 of those months in beta.

  25. Nice editorial, Bob. I completely agree.

    As mainly a hobbyist, although I do use it in my regular career, I still feel that the 90 day release cycle is not good for anybody, not even the hobbyist. 90 days is not enough time to even do proper testing, let alone develop new features AND fix bugs. Because of this, RS, your customers are getting buggy releases that have a cumulative effect as each new release comes out. To really break the cycle, I don’t see any other way other then going back to a traditional release with several maint, releases. When you did this, in the days of 5.x and earlier, it seemed to me, again as a consumer, that it was more stable and less buggy.

    One comment I do not agree with above is that the end user should have to pay for bug fixes in features they already paid for. For example the Segmented Control is obviously broken based on the number of reports about it in the feedback system and on Bob’s comments. This is a perfect example of what happens repeatedly with new features under Rapid Release, they don’t always work in the initial release. Then they get fixes over the next few versions. But what if your sub ended with R4? You are forced to upgrade and pay for the fixes to the feature that you really already paid for and should work as advertised. That is the key flaw in the RR model.

  26. Well, the rapid release model is not the problem I think. For introducing new features, they should simply take more time. Like simply not including the SegmentControl in the final release and letting people test it more in the r5 alphas/betas before shipping it with r5.
    This is something I do often. Working on plugin release x for months and in parallel working on a big new plugin which ships with release x+1 or x+2.

  27. Christian Schmitz
    Well, the rapid release model is not the problem I think.

    Maybe not the entire problem. It seems that the mentality is that *something* new has to go into each release. That means that every 90 days we get new features that often don’t go through an entire alpha/beta cycle (heck, some features don’t become workable until *just* before the final candidates).

    Which is funny, because RS complains that we don’t give them enough feedback earlier in the alpha/beta cycle but because they generally have MAJOR bugs we can’t. So by the time final candidates show up it’s way too late for them to do anything about it.

    Talk about a circular argument….

  28. I created a new Feedback Request to stop the 90 Day Release Cycle. Feedback ID: 14252

    If you believe this to be a great idea, I urge you to spend one of your valuable points by making it one of your priority items.

  29. @Bob
    I’ll sign on to this and make it a priority item – just as soon as my currently-dead computer is resuscitated.

  30. @Bob Keeney
    Wow – I think you blew up the Feedback server, I was able to add it to my Favorites but then it blew up… “Connecting to Server” and hangs there 😉

  31. @Bob Keeney

    That new bugs are added in each release is not just a sentiment; we’ve been stopped at Rb 2009r2 because of such bugs. I now have a regression test program for our feedback cases.

  32. @Bob Keeney
    Remember, the reason that we have the 90 day cycle is because of the apparent hap-hazard way things were updated and released back in the pre-2006 change days. At first, I was in full concurrence with the new plan – it felt like we were getting something for our subscription plan dollars, but the result has been iffy to be polite.

    It’s also been bandied about that the program be changed so that for at least 2 out of the 4 releases in a year, the RS team focus 100% on fixing bugs. I agree with that whole heartedly. I’ve seen the “but look, we fixed XXX bugs in this release” notes, but I still see things like the Linux IDE bouncing around if you type below the middle of the vertical section in the code editor. Autocomplete still doesn’t handle members of a Class array. The Build Progress dialog displays the wrong project name if you gave a build process that opens and builds multiple projects…

    I believe that a 90BF / 180NF / 270BF / 360NF schedule could balance both the fixes needed and the addition of new features. Also, allowing a longer proving period for new features allows for a bigger opportunity window for the creation of the examples and documentation on the new features.

    Summary, I don’ believe dropping the 90 day release cycle will fix things – better defining what gets done in a cycle period will.

  33. @Christian Schmitz

    It’s not about crashes, it’s about speed. The new RBscript engine is slower than the old one for complex scripts. It is quite ironic that an update which was supposed to improve performance actually hurts it.

    What more shameful than ironic, is that RS hasn’t provided a way to use the old RBscript engine.

  34. @Bob

    Very reasonable post, I completely agree with you and most of the other comments too.

    Now, although I will sign on to your new feedback request and give it top priority, I fear it will be completely useless (even if it entered the top positions in the requests list). As I see it, this request goes beyond what the feedback system is for, and tries to dictate Real’s policy (on this concern). We are customers and as such we have to be taken care of, but that doesn’t give us the power to rule the compan

  35. (sorry for the unfinished message, it continues here)

    the power to rule the company. This is just my opinion, and I would very much like to see what would happen if this request made it into the top ten list.

    Julen

  36. Every company, that doesn’t have a monopoly market, is ‘ruled’ by it’s customers.

    RS doesn’t sell a “you’ll only ever buy one” product.
    RS relies on repeat sales to existing customers.
    RS is dealing with a fairly small potential customer base, in a pretty tight-knit industry, with a few competitors fast catching up.

    RS is TOTALLY ruled by it’s customers.

    How is RS going to finance anything if customers stop buying?
    If we stop buying RS won’t be able to fix the bugs/add the new feature to entice us to buy again.
    That’s a downward spiral to the corporate graveyard.

    Unless, of course, GP has a very large bank account and doesn’t mind RS losing money.

    In the last 6 months this general topic has been in the Mailing List, the Forums and now here.
    If RS isn’t listening AND doesn’t act, then I for one will be sad to see RS fade away…
    but I probably won’t notice because I’ll be long gone.

    RS is a brilliant product, created by a bunch of geniuses and it has such amazing potential.. but at the end of the day it’s just another tool in the toolbox, it either works properly or gets tossed out. Same as me screwdrivers.. 😉

  37. @PaulG
    many bug reports about segmented controls ?
    which one
    there are two – the web segmented control and the one for desktop apps
    the one for the desktop has 2 open bug reports that are not documentation related

  38. Well, I for one am tired of fighting my development tool.

    If things don’t get much better soon I will only be using REAL Studio for the simplest projects and I won’t repurchase since I’ll have no need.

    Because of it’s constant low quality I’m losing confidence in REAL Web also.

    Why should I spend $600.00 for REAL Web when I’ve been betrayed by REAL Studio time and time again?

    Why should I believe REAL Software will have a higher quality with REAL Web than REAL Studio?

    The problems with REAL Studio exist because of poor development decisions.

    Same company in charge of both projects, same problems.

    I don’t want my success or my projects to be dependent on REAL Software ‘someday’ fixing things when they decide to fix them.

    No thanks.

    I’ve had years of that BS already with REALbasic.

    I feel betrayed and I’m upset.

    It might be time to learn free tools like Xcode 4, Javascript, PHP and the rest.

    With Mac’s market share now being 50 million Macs plus iPhone, iPad and iPod it make sense to start learning Xcode 4 and using it to develop especially with it’s new one window IDE.

    The thought of almost everything working and never having to wait forever for bug fixes or having the fear of not knowing if your bugs will even get fixed sounds refreshing to me.

    They may have a longer learning period but THEY WORK.

  39. @npalardy

    Our regression tests are all in a single project and so aren’t really suitable for attachment to a single project. But I attach example projects to most feedback reports that demonstrate the issue.

  40. @npalardy
    @npalardy
    When I did a search in Feedback for “SegmentedControl” 9 bugs came up and one feature. Yes you are correct that only a couple are related to the Desktop. I didn’t say “many” but I did say there were a number of them and there are. I also mentioned Bob’s testing and video too. It appears broken in Carbon and I question why it is even included in such a state for Carbon. I am referring to the icon stretching issues that obviously makes it look really ugly under Carbon. It is obvious that RS is pushing Cocoa and that’s where your future is for the Mac and I agree. But Cocoa is not in a state where you can ship an app with it, at least based on the comments and what I have seen.

  41. @charles
    Ah too bad
    They might help and i’d even hazard a guess that we could adapt them to be part of our regression test suite (to make sure things don’t regress)

    Yes – we have one … in fact we have two. One that stress tests the compiler and another that is framework related. UI is still the toughest to test with an automated suite.

    The projects attached to reports definitely help

  42. @PaulG
    It appears broken in Carbon and I question why it is even included in such a state for Carbon. I am referring to the icon stretching issues that obviously makes it look really ugly under Carbon.

    Is there a bug report for this “icon stretching issue” ?
    I can’t find a report for it.

  43. I like the rapid release cycle and setting it at ninety days seems reasonable. What could be improved are the stability of new releases, rate at which bugs are fixed, and consistency of framework behavior across operating system platforms. None of these will ever be perfect but they can each get better.

    May I suggest following the lead of Canonical and having a Long Term Support (LTS) release every fourth release. That’s once every two years for Ubuntu but would be once a year for REAL Studio. Canonical also has a rapid release cycle and incorporating LTS releases works well for them. The REAL Studio LTS release would include few, if any, new features and would be primarily dedicated to stability. The LTS release would receive updates to fix bugs until the next LTS release. Timing could be forty-five days for the first update followed by ninety days for the next three updates. That would place their release dates in between the release dates of the non-LTS releases. The non-LTS releases would continue to include bug fixes but have more emphasis on new features to keep the product moving forward. Professional software developers releasing commercial products could stick with the LTS releases of REAL Studio knowing that they would be the most stable. Hobbyists, and those not willing to wait for a LTS release for new features, could use non-LTS releases. REAL Software might benefit from having a very stable release each year on which to build new features. The IDE could be built with a LTS release to ensure a high level of stability and consistency across operating system platforms.

    Regardless of whether or not REAL Software adopts LTS releases, more effort should be made to have REAL Studio behave consistently across operating system platforms, fix bugs in a more timely manner, and more thoroughly test new features before releasing them. Better documentation of those new features, as well as existing ones, would be equally beneficial. One of the lessons I’ve learned after decades of developing software for large businesses, especially stock exchanges, is that stability is more important than performance and performance is more important than new features. Some people may debate performance versus new features but we can all agree that stability matters most.

    REAL Software is a great company and REAL Studio is a great product. Great is not perfect but greatness can be improved upon by striving for perfection. In this case, great stability and consistency, followed by great performance, with occasional great new features would be perfect for me. I wish Geoff and his team my best in responding to all the feedback his customers have provided.

  44. I think @Fred Roller’s idea for a LTS is great idea.

    I’ve been using RB since 5.5 and am currently on 2010r4. I think the RS rapid release model is unjust. We shouldn’t have to renew our
    subscription to fix bugs in controls introduced in a version we paid for…

Comments are closed.