Upgrading Delphi, or Not: The Issues At Hand, from One Customer's Personal Perspective

I had a great dialog/chat w/Nick Hodges and Chris Benson from CodeGear (Delphi Product Manager and Delphi Senior R&D Engineer, respectively), yesterday at CodeRage.  They were tremendously patient w/my questions about upgrading (I've been coding a long time, and using Delphi/Turbo Pascal for years, but have much still to learn about raw component development and architecture, which affects migration and upgrading ease tremendously).  They also seemed refreshingly interested in helping, and in hearing this customer's perspective as well.  I appreciated that.

Today, Chris posted about the chat, and offered some thoughts on it (thanks Chris).  I'll respond to some of it here:

Chris said:

"First you have to understand how I use Delphi on a daily basis is completely different than how you use it. We develop Delphi in Delphi. Our version control system contains nearly every line of code that goes into the product. So for me upgrading between versions isn't as much of an issue. Plus there is an entire team of Delphi developers to help out. So I'm trying to put myself in your shoes here."

Chris,

Thanks.  My shoes are probably quite a bit smaller than yours, but they get me around my part of the park quite well.  Hopefully they'll fit your feet OK.  ; ) 

I do definitely recognize that you guys live in a different, more malleable land.... and also have the chops and specific knowledge that make library upgrading intuitive and a relative no-brainer for you -- which is largely why I spoke up.  I think, personally, (especially after our convo yesterday), this problem is a bigger one for you (CodeGear) marketing and momentum-wise than maybe you guys even realize.  Delphi rockstar Marco even said it's a big issue in his opinion (separate chat).  (I felt pretty validated with that latter item.  <g>).   

You said:

My perception is that 3rd party components and IDE plugins are your biggest concern. If a 3rd party component doesn't support the latest version and the source isn't available you might as well just stop and use the version you have that works. This is the same problem when upgrading any complex system such as an OS. This is the same reason I'm not upgrading my Mac at home to Leopard.

YES, these are definitely my biggest concerns -- the showstoppers that killed my BDS 2006 upgrade attempt, and still currently prevent me from buying Delphi 2007 for Win32. 

BTW, the "complex system" factor you mention is exactly why I'm running Delphi in its own virtual machine, which meant when I bought a new laptop two months ago I didn't have to re-create my development environment -- just copied a folder over and was off and running.  It's also why I'm seriously considering buying a different laptop, so I can run WinXP while Microsoft and a few key software/hardware vendors get the kinks worked out with Vista over the next year or so.  I'm not a Luddite, any more than you are... but the bottom line is that pragmatism rules my computing day...

- THE PROBLEM IN A NUTSHELL -

I think Cheryl nails it with this comment on your blog.  You guys should maybe print those three items on a big poster and put it up in the CodeGear office.  : )  I want to want to upgrade, but the cost-to-benefit for doing so has to be compelling; not just in the smaller, CoderGear-centric picture, but in the much larger, much more complicated, end-user/developer-centric picture.  I'll quote her here, just for context:

There are three main reasons for upgrading:

1. The old version is seriously broken in some way (certainly not the case with Delphi 7);

2. The new version contains features that a client wants that do not exist in the old version (e.g. a client is moving to Vista and wants certain Vista-specific features that only the latest Delphi supports);

3. The new version will so markedly improve productivity that you just have to have it (by no means proven as yet).

If none of those criteria are met it comes down to a question of how much the upgrade is going to cost, both in money and in time and effort to migrate. The answers to the latter are often very hard to find, and bitter experience suggests that migration costs are often much higher than the software supplier's rosy predictions suggest.

For #2, I would also add that this isn't just about what end-use clients want; new features that *I* find compelling count the most. ; )  The quick-search on the component palette is an example of something compelling to me -- especially now after seeing in Ray Konopka's presentation yesterday that's he's updated his Delphi IDE Palette Menu (another IDE plugin I've come to absolutely depend on).  Core Vista compatibility is example of another.  (OK, maybe there's some irony there with that last one, but I digress... <g>).

- SURVEYING THE MARKET -

I mentioned in the chat room that I see Delphi as more an ecosystem than a product.  To me, it's a platform, not just a development tool or environment.  That's its beauty, and that's its power... but it's also, I think, the key weakness you guys face in getting people back on the upgrade gravy-train.  Metaphorically speaking, the problem isn't as simple as just upgrading the coral, and expecting all the fish to come along for the ride.  You also have quite a few years of post-Inrpise, pre-CodeGear lack-of-focus stupidity to overcome, especially with third-party vendors.  I personally feel like you're doing great at getting the momentum of the community as a whole massively moving forward -- the coming mini-flood of Lulu.com Delphi books I heard about are a good example and indicator of that, IMO -- but the rumblings (or silence) I hear occasionally from the 3rd-party vendors indicates to me that you've got some wooing, relationship-building, and motivating to do there still.  (I'd say DevExpress is a good example -- why weren't they at CodeRage II?).

- MY OWN BLURRY, AT-A-GLANCE, COST-TO-BENEFIT EVALUATION -

Cheryl's last paragraph above is my story; I had a lot of time wasted, a somewhat bitter experience (greatly tempered by my prejudices favoring Delphi and you guys as a company), and money lost on both BDS 2006 and the Raize 4.0 component set, neither of which I'm using at all now.

Nick's upgrade advice, and related assurances re: the ability to install 3rd-party components into the Delphi 2007 trial version (using the CodeGear RAD Studio 2007 Trial downloadable here, for those interested), will probably be sufficient to lure me to invest the time (which I suspect will end up being measured in days...) to try again.  If I succeed w/that though, do I have to do the process all over again when I buy the "real deal" version / license?

Just for some broad metric on this, I ran a search of "*d6*.dpk" on my Delphi dev box: 294 files found.  When fully loaded, my component palette has 117 tabs on it.  With respect to upgrading, should those two measures scare me?  Honestly, I have no idea.

Many of the tools/components I use are largely EXE-install dependent (the entire DevExpress VCL library and IDE plugins, Ray's (Raize) stuff, and numerous others for example).  Will they migrate OK using one-by-one DPK re-builds and installs?  Do I need to do that ~294 times?  More?  Less?  What about browsing path and library path updates, and help files integration?  Is that going to be a big, tedious, manual process?  Those are the kind of vague, hard-to-answer questions that look and feel like time-and-money black holes to me.  My experience in the past has amplified that feeling.

- IDE PLUGINS -

Anther key aspect of all this, is that Delphi IDE plugins are so well-integrated that once one has settled into using them, it's easy to forget where the IDE ends and the plugins begin.  It's wonderful that they're like that, but it also blurs the upgrade decision problem.  I use CodeRush in Delphi 6, for instance, which unfortunately has been abandoned by DevExpress on the Delphi platform, so losing that is a cost even if I were willing to pay the upgrade money to them as a 3rd party.  CodeRush adds a LOT of functionality to the IDE, but so transparently (and I've used it long enough) that I now can't even tell you what all that functionality is.  What of the new IDE features replaces my need for it?  How does Castalia compare, and what does it cost?  Does GExperts fit into this at all?  Are it and Castalia compatible?  Again, more questions here than answers.  Does anyone have a features matrix on those four items?

I mention above that I'm not a raw code-based, ground-up component-development expert (yet!).  I'm primarily an application developer.  As such, another IDE plugin that's been tremendously valuable to me is the ExpressClassDeveloper Suite (formerly Eagle Software's CDK) -- I've learned most of what I know about component development just playing w/that, and have built probably a dozen components that started there.  Ray's presentation on components and Frames-based composites was helpful and compelling (I've done lots of TFrames stuff, so the latter is a hopefully-small leap), but still, this is an example of another tool I will basically lose when I upgrade.  (Again, the community is key here -- I have Ray's Developing Custom Delphi 3 Components PDF (still largely applicable, as I understand it), and am working my way through it).  Maybe after upgrading I should keep my Delphi 6 setup in a separate VM just for this? Who knows....

- FULL-SYSTEM APPLES TO APPLES -

I'm a latecomer to the Delphi upgrade party; I know that... but I'm also pretty confident that there are thousands of folks -- probably tens or perhaps even hundreds of thousands of folks -- who are basically the same position I'm in, thinking these same kinds things, and facing these same kinds of quandaries.  I remember reading parts of the threads in and around Nick's posts in the past on the upgrade subject, before the "hey-CodeGear-really-is-listening" release of Delphi 2007 for Win32 this year.  I couldn't help noticing the din of people who "called foul" on "new Delphi features" that they already had via 3rd-party components and plug-ins.  I'm not calling foul, but the reality is these 3rd-party items really do factor in mightily re: the what's-compelling and what's-costly aspect of the upgrade decision.

* * *

All that said, let me say this: Keep up the great work, and thanks again for all you guys are doing.  Thanks too for making the smart choice re: having CodeRage attendance be free. (2100 attendees from 100 countries? Wow!).  It was great fun, hugely informative, as well as encouraging and invigorating I think to all who participated. 

Lastly, this:  I'm pretty sure you'll sell me eventually at some point.  I'm just trying to make it easier for you. ;-)

Comments

[Sheree Ervin]

This is great feed back in order to continue our testing for project importing. If you feel like emailing me with additional details about your plugins and components, I'd like to give them a try and see what we'll see from a testing perspective. Please send me an email at servin@codegear.com if you would like to persue this.
-Sheree

[Eric]

how I wish we can just upgrade our IDEs without uninstalling anything and all 3rd party will work with no worries.

[Julian M Bucknall]

You raise some good points about the efforts needed to migrate to a newer version of any IDE, in particular Delphi. I would tend to boil it down to "are the new benefits worth more than the complete hassle in converting/installing everything". It's essentially the same equation for installing a new operating system.

CodeRush for Delphi is a good example of the problems you can face. It explicitly requires the IDE API that was available in D6 and D7 (I forget the name or initialism). For the newer Delphi IDEs based on the Galileo architecture, the IDE API changed completely, and in fact wasn't as broad as its predecessor. So it would have required a major rewrite and, for various reasons which are not worth discussing here, was never done, Instead Mark Miller, the CodeRush architect and principal designer, wrote CodeRush for Visual Studio, a vastly bigger market. I really couldn't say whether Castalia at al are a good replacement or not.

As regards our VCL controls, we've been keeping up with the Delphi releases as they come down the pike. Admittedly, changes haven't been that onerous for us up to now, but Tiburon is going to prove very interesting for us with the new Unicode support. Luckily for many like you, we've been maintaining support for D6 and D7 as we've been moving forward, but I'll have to say that Tiburon is likely to force us to start splitting code into "only Tiburon and above" versus "D6 and above".

Remember you can always email me at julianb@devexpress.com is there's something I haven't covered.

Cheers, Julian