Chris Bensen: Upgrading Delphi
It is always interesting (frustrating) following the upgrade/stick/switch turmoil that goes along with any consideration of moving from a stable devil you know tool versus the shiny new thing. Often the implicit upgrade cycle you would hope to happen is hindered by a slow release cycle on the tool of choice or lack of compelling features. These items have been beaten to death by others but I thought some personal insights from similar struggles I have seen may as well be added.
In any upgrade it is generally the "little things" that surface to haunt you so anyone that has been through a prior upgrade always entertains the idea that there are many of those gremlins just waiting for a chance to laugh at you publicly after you have deployed to your clients.
I participate in two significant products, one based on Delphi 6 and another still on Delphi 5. In both cases the volume of code, testing capacity, and potential re-platforming as are always cited as significant barriers to attacking the upgrade cycle. Due to 3rd party dependencies the latter project has an extremely high bar for upgrading. In both cases the problem is firmly rooted in not carrying out a natural and continuous upgrade cycle with robust testing. Until you have the "must have" in the new version you can't really afford to make the move. The business case simply does not exist and diminishes the further you get from the tip release of you development tool.
Rather than suggest you should not upgrade I think a pragmatic approach that I have found moderately successful is worth highlighting. For much of the server components of one of the products the code has been maintained in each new release of the Borland/CodeGear toolset but always back-compiled and tested using Delphi 6. So, all along the code was maintained in Delphi 7, BDS 2005, BDS 2006, and finally in RAD Studio 2007. That is great, after getting over the the initial hate for some of the IDE changes (SDI) you start to rely heavily on the new features like live templates, refactoring, code metrics, and models. Still nothing new is needed for the product that goes out the door though so upgrade sell is weak based on a "feature case."
But there are definitely reasons to upgrade. Recently, we were doing capacity testing and were a bit disappointed with our numbers and needed a quick hit. Without a single change to compiler options, code base, etc. we performed the same capacity testing with the application suite complied under RAD Studio 2007. We immediately saw a consistent 25-30% capacity volume increase. The majority of this is easily related directly to the the new memory manager (FastMM) and better inlining of key functions. Most of these items we could get if we were willing to alter the system to include or use 3rd party tools but the whole point was OOTB improvement. Since it was server-side code VCL changes really were not a factor.
We did not need the increased capacity immediately so we simply tucked it away in the "good to know" column. Had we needed it I am sure an upgrade on the server components would have happened right then (not a strong enough business case). We are now taking steps to assess a full upgrade on the client and server components and work out a process that will not leave us hung on an older version as we are now. What is the biggest hang up? Proper coverage for the testing. You can never have enough and dealing with tool related problems is never a good sell. An upgrade advisor tool that can run on a project would certainly be nice to have.
Over time though there has been a persistent set of issues that never quite seem to be addressed when you are trying to push a particular upgrade. Don't get me wrong, I am fully in the "upgrade often and stay upgraded" column but this list contains the items that most often leave me hesitant:
- Install Experience - What you get after you finish the install is great... but getting there is appalling and there is no amount of counter argument that can ever suggest it is acceptable. Most persons that have installed any recent BDS/RAD Studio have most likely installed other products that are equally complex. I can get through OS + Service Packs often faster than I can do the same for RAD Studio. Suggestions that this is an MSI (Windows Installer) problem only serve to alienate those who actually know that it isn't MSI, rather it is how it is being used. MSI may not be fun but it is often a necessary evil.
- Software Assurance vs Upgrade Cost - Upgrade costs always factor. The problem is they shouldn't, CodeGear has a fabulous subscription service called Software Assurance. While information about Software Assurance is more readily available these days it is still difficult to get your head around it and why it makes so much sense. Make subscriptions the only sales model and show clearly how your frequent release cycle makes this a cost benefit. There are blogs and even calculators out there that demonstrate this but "direct from CodeGear" means something.
- Difficultly in showing the big benefits - The integration of dUnit, nUnit, MS Build (hmmm, wanted NAnt myself), FastMM, for each looping, code metrics, refactoring, generics, live templates... the list goes on and anyone following along with the upgrades is inherently aware of them and enjoying them but each of these is small by itself and information on them is more often found in blogs or secondary sources. These factors all play into quality and effort reduction improvements in our own projects in terms of quality, defect rates, and performance. The leading question is how do you turn that into a strong business case. The sales pitch "have less defects, more developer time, and a faster more robust product" may exist on the CodeGear site but I haven't seen it.
- Documentation - Having used Delphi for so long I can't really appreciate the documentation woes that exist but on the occasions I find myself hunting for something in the help I realize just how difficult it can be for an OOTB experience. The help has been improving in first-use and correctness with each release but in some ways is still not on par with Delphi 7 and earlier releases (the language guide is still hard for me to locate to this day). The "little things" kill you here. Try finding the list of VERxxx compiler defines... (tell me if you find it).
- Features only beneficial on new projects - ECO... everything I have seen and played with suggests this is a great addition to Delphi but the fact remains it is similar to re-platforming when it comes to making use of it. Give me MAC's, 64-bit, Unicode and even CF. These are core improvements I can use on products that have hundreds of man-years invested.
In the end the Delphi product is targeted at developers but the install process is so burdensome that it is difficult for a business application developer to potentially have to spend time on assessing and using the tool when the install experience takes up valuable time and leaves the wrong taste in the mouth and leaves little for a concrete experience in the software.
After all the non-positive comments above I still have to say that the upgrades are well worth the effort but that is more from the fact that I know the benefits are in there from constant exposure to them as opposed to looking at any given
information on the CodeGear site and going "Wow". So, if you have been hedging on upgrading I strongly encourage you to get past the OOTB experience and get used to the product. The benefits are there and your productivity will actually increase. You may even like the SDI interface after some time ;-).
Chris Bensen: Upgrading Delphi
Why aren't you upgrading Delphi- Reasons and myths
