On Upgrading Delphi

Back from Delphi Developer Days (Kudos to Marco and Cary) and after cleaning up the mess in my inbox I would like to share some thought I had during one of the sessions named “Delphi: Today and Tomorrow”.

Some of the attendants mentioned they were still working with older Delphi versions and even if the newer versions were laying around they refused to make the step migrating their applications to the current Delphi XE. One argument from a fellow developer working still with Delphi 2007 actually alerted myself as he rated the step from Delphi 2007 to Delphi 2009 a very big one regarding the Unicode migration, but the step from Delphi 2010 to Delphi XE seems rather small, which makes himself unsure wether to make the migration to Delphi XE now or wait for the next version to come.

Honestly, I don’t get that. There already is a large step from Delphi 2007 to Delphi XE. Why making it even larger? What about “divide and conquer”? Do you really expect the migration to XE2 being easier than that to XE?

The big step, at least for some of us, may indeed be from Delphi 2007 to Delphi 2009. For myself it was merely waiting for the third party libraries to keep up or to replace some of them with those currently supported (OK, that has been some work). The steps to Delphi 2010 and Delphi XE were simply opening the project, compile and start using the new features.

Since migrating to Delphi 2009 I have been able to make use of all the new and exciting features that made it into the product since then. My code and my coding has improved a lot. I learned a whole bunch of new technologies and new techniques that makes my programming life easier. Staying with Delphi 2007 would have been a huge loss of time. Time to work with new technologies and gain experience.

When Delphi XE2 will be delivered I can concentrate on what is new in that version. I am eager to make my applications compile for the Mac (remembers me that I have to buy one before). I can’t even imagine to bother with Unicode, Generics and Anonymous Methods at that time.

IMHO not keeping up with the current Delphi is similar to not using version control, only the other way round. While using version control allows you to revert to a previous version of your application easily, staying up-to-date with your Delphi version allows you to create the future versions of your applications much easier.

Author: Uwe Raabe

Addicted to Pascal/Delphi since the late 70's

28 thoughts on “On Upgrading Delphi”

  1. Every time I read post like this I wonder it those writing have ever worked on large projects in a large team. Upgrading to a new Delphi release means: 1) upgrade all team licenses 2) upgrade all libraries used, and ensure they are available for the new release 3) Upgrade and **retest** all code to ensure new bugs (and even fixes!) or changes do not affect your application. Well, it could be a long and expensive task, and usually I am more occupied to add more features (and value) to our applications and sell them, not to ensure Embarcadero has a constant stream of money. The Unicode upgrade could be a big roadblock, because you may have to change a lot of code, upgrade databases, change libraries if you use some old ones that may not be ever ported to Unicode releases. And some new features – dbExpress/Datasnap are not so appealing due to their bad design and implementation.
    Porting to new Delphi releases needs to be planned when they make sense for your needs and you business, not just because a new Delphi release is available and Embarcadero needs some fresh milk from Delphi.
    Porting to XE2-32 bit will not be more difficult than porting to 2009, 2010 or XE. Porting to 64 bit will be another task – but I really see no reason to spend a lot of money now to upgrade to XE when a more capable product should be delivered soon.
    For the matter, applications like Apache are still compiled with Visual Studio 6, and I wonder if these articles are Embarcadero-sponsored or not, given most Delphi “consultant” became resellers as well, it’s a kind of conflict of interests I do nor really like.

    1. Actually I left out the decision to upgrade Delphi due to the price. I know that this is an issue for some people, but that this another story. I guess I mentioned that there were versions of Delphi 2010 and XE laying around to be used, so the price was not relevant. I guess I also mentioned the library issue.

      Regarding the test when upgrading: I use to have automated tests for my applications all the time. These are simply run with the new Delphi version without any source code changes (except some adjusted IFDEFs where needed). I can see not much additional work needed here.

      Of course the migration to XE2 will be not much more difficult as the migration to XE (as long as Win32 is the target), but the catch-up of the new features will be.

      I wonder if Apache were still compiled with an old version of Delphi if it were developed in Delphi right in the first place.

      And just for the records: I’m neither sponsored by Embarcadero nor am I a Delphi reseller. The article simply reflects my own opinion as your comment does with yours.

      1. Leaving out the cost issues, you have left out one of the biggest drivers in taking such decisions. When you have to spend tens of thousand of euros to upgrade, while stopping new any development while you upgrade your code, the libraries, and maybe rewrite whole parts to change to new ones (we employ automated tests, but such changes would trigger a whole quality assessment and validation, which is long and complex, because apps need certification) , you have to justify the business value of that. Most developers would like to play with the latest features, but I can’t put a project at risk just for using the latest features. Our customers don’t care if internally we use new features but of no value to them – any upgrade needs to be planned and aligned with our business needs, and our customers’. I don’t see catching up with new features an issue – Delphi didn’t introduces nothing new that wasn’t already available in other languages.
        About COI, I apologize with you, but lately I see there are two kind of Delphi developers: those who simply code in Delphi and just make money from applications written in Delphi, and those who makes money from Delphi itself, selling it, training, books, etc. etc. As Delphi issues grew, I started to see a more biased approach from them, I understand they need to keep their market alive, but that’s a kind of COI that forces me to take their opinion with caution.
        About Apache, InnoSetup was compiled with Delphi 2 until it needed Unicode very lately. And I know of noone who complained it didn’t work well because it wasn’t compiled with the “greatest and the latest”. User judge what you deliver them, not what you use to deliver.

        1. Uwe. This is the Microsoft life cycle for products. 2 to 5 years new things – 5 years maintenance. Delphi has a good standing from the concept after first n years in terms of the OS life cycle. Delphi is not for the innovation period of the first 2 years, Delphi is for the second 5 to 8. Usually this is no problem as a Windows OS takes long to spread and it seems it is the lifetime of the device bought.

          You are in Germany, Austria is little different, you are in the worlds average – simply because of the population – so you still had a huge number of XPs until this year. Honestly a D2007 application will work for the next 10 years on Win 7. If someone says I want it this way …

          The risk people run into is simply that one day they sit on legacy very costly to migrate and finally not done, this will happen to non UNICODE apps that are not already ported. Assuming they are older and in maintenance – I doubt someone would pay for having them on UNICODE in many cases if there is no need for UNICODE.

  2. Porting a large project (or even worse: porting several interconnected projects) to a new Delphi version wasn’t a big issue until the step from Delphi 2007 up to Unicode enabled Delphi versions. I am responsible for such a project and even though I have been using Delphi 2010 and XE for some smaller and private projects and I definitely would like to start using generics I hesitate taking this step for the large project. The main issue is the change of String from AnsiString to Unicode String because they were misused for storing binary data in many places.

  3. We convert a large project for each new Delphi version, in order to protect our very large investment. The Delphi XE RAD licenses are just 2-6% of the total running costs, thus not a lot.

  4. “I learned a whole bunch of new technologies and new techniques that makes my programming life easier. ”

    Could you give us some examples please and describe how they have made things easier for you.

    I’m always quite sceptical of new techniques since there’s so much hype floating around. Adding a new technique to your toolbox is, for me, always a careful consideration of what it give me (in terms of productivity) compared to what it will cost me (in time). Of course, it’s not all that rational, it’s also fun (and good for you) to learn new stuff but there is only so much time at hand.

    Anyway, ‘to upgrade or not to upgrade’ remains a subject that evokes quite a bit of passion. Personally, I found the step to Delphi 2009 surprisingly small and since most of my applications are multi-lingual, it was more of a relief than anything else to finally have a proper Unicode system and not just some scattered Unicode-aware components.

    1. The use of generics made a whole bunch of individual container classes obsolete. The generic classes have already built in some functionality that otherwise had to be implemented in each individual class separately – thus it was never made. Together with anonymous methods sorting an array is mostly a one-liner now. Synchronizing from threads with parameters is made so simple using anonymous methods. Just a few that came to mind.

  5. I agree with LDS. I’m sure that Borland / Inprise / Embarcadero never realise the effort required to upgrade. There is no shortage of willingness but we have two jobs – to keep producing / fixing / upgrading our own software and then a parallel task to upgrade all the libraries and Delphi. Although the Unicode issue ‘only’ took me about 1 year to sort out, I’m still only ‘check-compiling’ my 1,000,000 lines of code in XE but it is still released using D7. I’d dearly love better attention to more automated means.

    1. Sorry to hear that, but my experience was much better while the application is about the same size. The biggest problem was actually an open source library that has to be kept compatible with older Delphi versions. Life would have been easier without that.

      I had to drop some very old libraries not supported anymore, but that would have bitten me sooner or later anyway. Being forced to do that turned out to be a great relief and gave my apps a fresh new look.

  6. Regarding the Migration of several Oracle C-S Applications:

    The DevEx QtmGrid component suite Cost seems greatly reduced, and this rich package is still maintained.

    AllroundAutomation Oracle DOA components are rock solid.

    D2009+ IDE’s have been a joy to work with:)

  7. conspiracy theories are fun! Almost never correct, but fun all the same. 🙂

    I upgrade to each new version of Delphi (Rad Studio) and upgrade any ongoing projects when it makes sense. I’ve done this since version 1. I agree with Uwe on the benefits, and I’ve only had one version that was so bad out of the gate (unpatched Delphi 4) that I rolled back to the previous one.

    I don’t do this as a way to keep Embarcadero in business. I do it because it makes sense for my (very small) business. For the record, SA is a pretty good way to keep more of that money in my pocket instead of theirs (sorry, guys…).

    My comments are also not Embarcadero sponsored. It’s kind of a ridiculous claim.

    And yes, I have worked on large projects involving large teams, sometimes involving people in different countries.

    @D Hovden,
    Here are some things (non comprehensive list) that have been introduced in Delphi that have had a significant impact on how I develop software:

    1) Unicode – I had a handful of applications that dealt with large amounts of Unicode data. Originally written in Delphi 6/7, moving these to Delphi 2009 made the code significantly simpler, eliminated the need for a bunch of third party controls, and made the software perform much better.

    2) Integrated unit testing – I’m constantly surprised when developers argue that this isn’t necessary.

    3) Debugging experience. Everything from improved inspecting of classes to debug visualisers to the under rated ability to drag breakpoints in the editor. When I need to debug code, these make the whole experience much more productive.

    1. Your linked in profiles says:
      Current
      • Senior Developer (contract) at Embarcadero Technologies
      • Owner at Glooscap Software

      It looks like COI to me…

      1. My opinion of Delphi formed long before I did any contract work for Embarcadero.

        1. Maybe. But neverthless it would have been correct to inform the readers you are an Embarcadero employee, even if a contractor.

          1. No maybe about it. I was pro Delphi for a long time before I did work for Embarcadero, and I continue to be now that the contract has finished.

            Any other questions?

      2. As I think about it, this is how I purchase all of my development tools; Get the subscription option if one is available. For example, my MSDN subscription.

        1. If everyone bought subscriptions, the vendor would have no financial motivation to innovate.

          1. You could argue that more subscriptions give the vendor more incentive to fix long standing problems and improve existing features instead of investing the majority of their time on big ticket features intended to drive the next sales cycle.

          2. That only depends on what the subscription is. MSDN is a valuable subscription, Emb SA is not. Besides getting a new version paying very early in advance, you get very little. MSDN subscription delivers **a lot** more.

          1. Even though I’ve never worked for Microsoft? Interesting.

            Do you also believe that any pro-Delphi blog posts must some how be sponsored by Embarcadero?

  8. I have a question re automated tests: could some of my more knowledgeable colleagues point me to an online resource explaining how to do these automated test for the visual interaction part of the application; I find that 90% of the bugs I have in my apps are not on the business logic or database level, but on the end user interaction with my apps.

    I am maybe a poor programmer but this is the reality I am facing and I do not see how DUNIT can help me, but I am willing to learn.

    thanks in advance
    Didier

    1. I guess there is something like GUI testing in DUnit, too, but I have never used it.

  9. Disclosure: I am an Embarcadero Employee. But leaving that aside for a minute… Prior to being employed at Embarcadero, I always purchased Software Assurance and upgraded to new Delphi versions. Everything I state here is exactly what I would say, whether I worked for Embarcadero or not.

    Also, because I’m a nice guy — I am not going to tell anybody else what to do! But I am going to mention a few things that I think anybody who decides to stay on one version forever should think about:

    If you’re going to factor all those costs of moving into your rationale for “not upgrading”, why don’t you also include the costs of staying put? I hope you can make that list all by yourself, because the list will be different for different people.

    The costs of staying put for ME included:

    1. That the world is Unicode now, even if you are only writing English applications, you are still going to eventually need to produce and consume file content like XML in unicode, that’s the way everything’s going. I had a major application that read/wrote .XLS files. I didn’t even realize that XLS files have been unicode for a long time now, until I had a Korean customer (who speaks english and uses my application in english) complain that the software corrupted his Korean .XLS files.

    2. That the community has moved on past Delphi 7, and that staying on Delphi 7 forever (which remained my favorite version until Delphi 2009) means getting less peer support, and no support from any official sources.

    3. That the Windows world is moving to a Windows 7 dominance, and XP is fading out, and that certain bugs and problems in Delphi 7 are going to continue to cause problems for you. I could make a big long list here, but the only one that is going to matter to you is that one that you spent six months working around. Maybe it was Z-Order. Maybe it was something else.

    What I find is that some developers add up all the time they spent ad-hoc-ing around in Delphi 7 and use that figure in the “costs of upgrading” column, when they should be accounting a little less creatively, and calling a spade a spade; There is a cost to staying put, also.

    Warren

    1. Who said those who didn’t upgrade to XE are still using D7? There are some versions between, although some looks alphas and betas…
      In the past I did upgrade more often. Applications were smaller, Delphi was better, no ISO whatever compliance to follow… now what I would like to see is not SA to get releases I have no use for, I would like to see a maintenance “assurance” to keep releases mantained beyond the 3-6 months they are actually. And I would really prefer Embarcadero switch to a 2 year release cycle to deliver richer and more polished new versions instead of adding a bunch of third party tools and fix bugs for features I already paid for. Then probably I would see a value in their subscription. Right now MSDN is a good subscription, IMHO SA is not.

Comments are closed.