This is supposed to be something good right?
C++Builder 2010 is by far the best release for upgrading existing projects. I was able to open over 110 projects in an external editor, perform some text replacements via a macro for 3rd party runtimes, and rebuild all. And do it fast.
This is taken straight from the official What People Are Saying page on Embarcadero’s (once CodeGear… once Borland) about RAD Studio 2010. Seriously? As one might deduct from this statement, it is not a pleasant experience for the existing users to perform their project upgrades to the latest version of RAD Studio. However, I’ve learned that very little change can happen by being a prick about everything. Therefore, in the spirit of trying to stay positive, let’s approach this in a diplomatic way.
Upgrades are great and all, but I don’t have the luxury of our software ALWAYS building on the freshest version of development tools. At the same time, I don’t let the environments get too stale. Within the last few months, I took the upgrade from RAD Studio 2007 to 2009. It’s always exciting to get on the latest version of the software to see what new features, speed improvements, etc. are available. Part of the reason behind not going to the 2009 version sooner was because of the long, drawn out process I went through with the 2006 to 2007 version. As with most IDE’s when a new version comes out, there is inevitable changes to the project files. This proved to be the pain point I had faith that the experience must have gotten better and that the 2009 upgrade would be a breeze. Unfortunately, this was not the case.
For customers that pay the hefty maintenance price (approx $6K/year for us), the experience and pain to upgrade projects is atrocious. Especially when expectations are being set by having an automatic project upgrade feature in the IDE (which most IDE’s have as well). Oh sure, I open the 2007 version of the project file and the IDE automatically converts it to 2009 but nothing builds! In order to get things working, some TLC and pixie dust is required.
While I won’t go into details, I’ll just say that the experience was tedious and very much like the person described in the quote above. One HAS to actually create scripts to properly modify the project files in a predictable and repeatable pattern. If you didn’t you risk a great deal more doing it manually, by hand or through the IDE. We never get it right the first time and being able to back out a project change, modify the script and try again saves so much time in the end. Without a script or some type of automation, the amount of work to upgrade the project files is directly proportional to the number of project files! This begs the question, why not make this experience better and built in to the software. If a user can script it out, why can’t the people that make the software and dictate the new project file requirements?
As with any software company, priorities get set to work on certain features and the input usually comes from a variety of sources:
- Marketing and sales for the new potential users
- The request from existing users of the software
- Internal engineering input on refactoring and bug fixes.
- Etc.
I have a hard time believing that the existing users of the RAD Studio product line have not complained about the project upgrade process between versions. One would think they’ve experienced the same sort of things I have. There is a reason for everything so the fact that it has not been addressed is a logical one.
- Maybe it’s not painful enough yet for the existing user base to yell.
- Maybe it’s very painful but the existing user base is not yelling loud enough.
- Maybe there is no friendly way to acquire feedback from the existing user base.
- Maybe the existing way of acquiring feedback is not effective.
- Maybe the existing user base has given up because they’re just used to second class treatment (hope not)?
- Maybe the existing user base that is giving feedback only represents a small percentage of the total.
These are hard questions and only the software maker truly has a shot at answering them (or asking new questions all together). What I do know is that as an existing user I find it frustrating when a blog post comes out talking about how the MOST requested feature that made it into the 2010 release is a complete rework of the the Class Explorer. Are we serious here? The Class Explorer was at the top of the list? This doesn’t make sense! Isn’t there better things to work on than investing in a complete rewrite of a small IDE feature? Do people actually use this kind of thing anymore (or ever)? Well, according to the existing users that that are giving feedback, the answer is yes.
To me, this seems like a feature that was played with when RAD tools started going mainstream (circa 1990’s?). A cool idea that somebody thought would help illustrate this new idea of a RAD environment, by visually displaying the class structure of the file being edited. I don’t use this feature and cannot see myself ever doing so. For me, there has never been a substitute for actually reading code in an editor. That’s just me though, and I’m a small percentage of the existing user base.
In all honesty I could be at one extreme of the user base, while the majority use the class explorer to navigate their code. Coming from a Unix/Linux background this may just be my preference. Who knows. It just illustrates why being in touch with as many different types of users when getting feedback for future development is so important.
Unfortunately, every new release of the RAD Studio product line that I’ve experienced ends up taking down 1-2 weeks of time to perform the project upgrades. In my opinion this type of work is an unnecessary waste.
Please make it stop for the love of your users!
The last few have hurt so bad that I truly question whether the upgrade is worth it or not. I always end up convincing myself that it is worth because that’s the programmer geek in me who cannot resist the new stuff. Please don’t use this against the users.
The fact that an upgrade can be scripted out via regular expression search and replace is not a feature, but a shame.