Dear Real Software,
Thank you for a wonderful product. It has served me and my clients well for over a decade now. I can think of no other product that is as easy to use yet as powerful and flexible as Real Studio. It really is a great product and I have no problems recommending it to others.
I have been critical of Rapid Release Model in the past and will probably continue to do so in the future. I feel that in too many cases incomplete features and documentation have been released simply to fit the schedule. I have advocated for fewer releases or releases that stagger bug fixes and new features because I have been bitten, too often, by needing a bug fix in a new release just to be bitten by a new bug somewhere else in the product. It’s very frustrating for me and my clients.
Unfortunately, at this point in time, we are experiencing the opposite effect. You see, you have been telling us for over a year that we need to be testing Cocoa because it’s the future. We’ve taken this to heart because we don’t care to get caught with our pants down. In addition you’ve also told us that bugs in Carbon, unless critical, won’t be fixed. This leaves us between a rock and a hard place for our Macintosh builds because we have projects (for paying clients) that can’t be built using Carbon because of bugs, and we can’t build for Cocoa because of Cocoa specific bugs.
We have similar issues with Web Edition apps. We have a number of very critical bugs that are affecting our delivery of web apps to our clients. Sadly, what makes this situation hard to deal with is that those bugs are marked as fixed and are only awaiting a new release.
We all know that the goal is to have the 2012 Release 1 be a 100% Cocoa Mac build. We also know that it is a completely redesigned IDE. Both are laudable goals and I can only imagine the complexity of managing both of those projects simultaneously.
Real Studio Release 4 was released the week of December 5, 2011. The three dot releases fixed some hugely critical bugs but contained just a few changes. I understand that all hands are on deck to get the new IDE up and running and Cocoa polished. No one is denying that it’s not a huge job to undertake all that at the same time. I question, however, if you really have the resources available and the proper planning in place to accomplish these goals in a timely manner without understanding the ramifications to your customers.
It’s now been 120 days since the last major release. Frankly, I don’t care about the 90 day release cycle but it leaves a foul taste in my mouth when you tell us to use Cocoa because you need more feedback and then stick us with a release that has bugs in both Carbon and Cocoa. Unfortunately, there is no end in sight as there is no release date set for 2012 Release 1 and, as far as I know, R1 is not in beta testing yet.
This delay is starting to be intolerable. Your failure to plan and execute this transition properly is starting to cost me. So far, my clients have been patient. The really large projects are still on schedule but that’s about to end as Web Edition and Cocoa bugs WILL cause them to stop dead in their tracks. Do you plan on paying my salary and my employees while we wait on you to release a working and stable version? I’m certain that my clients won’t be willing to pay for projects that don’t work because of framework bugs.
Here’s my fear: You’ll release a new IDE with all of the Cocoa and Web Edition fixes but because you’re hurrying it through the testing process (because we’re all bitching for bug fixes) it will not be usable. If that happens I am doubly screwed since I have zero options. I can’t go forward and I can’t go back. I see this as a lose-lose situation for me.
I urge you to reconsider the Cocoa and IDE redesign in the same release. Let us, your loyal, paying, customers get our bug fixes so that you can continue working on the new IDE. I realize this change will greatly impact the schedule of the IDE. I also realize that retrofitting the newer framework into the older IDE is also a LOT of work if not extremely difficult. However, if going back to an R4 update is faster and more stable than the new R1 IDE then I say do it and I will applaud the decision and defend the decision to the end.
I know this letter probably won’t go over well but I’m looking ahead and getting nervous. I know you’re working as hard as possible but perhaps it’s time to rethink the strategy and go a different route. Engineering is about planning and adapting to changes. There is no shame in doing something different.
I hope I’m wrong and things fall into place. I’d love to pen a post saying thanks for a great release saying that all of my developers and clients are happy. I see many things that will make that hard to do. I am nervous and nervous customers are a bad thing.
Anxious and concerned,
BKeeney Software Inc.