Delphi Developer Dilemma

I've used Pascal-based compilers for a long time. Similar to many others like me, I started with Turbo Pascal 3 in the 80s, embraced object-oriented extensions in Borland Pascal, attempted to understand OWL but quickly moved to Delphi when it was released, and now churn out blazing database applications on the latest Windows operating systems using internet technologies, advanced reporting tools, and multiple third-party component sets. Sure, I've dabbled in other languages such as C/C++, Visual Basic, .NET with C#, and some scripting languages, but Delphi has been the bulk of my experience for the past 17 years or so.

Since Delphi 2010 was released, I've felt myself searching for reasons to upgrade to newer versions but not finding a seriously compelling reason to do so if my applications simply continue as they are--Windows-based programs using the VCL and client/server databases. The IDE is quite capable, there are few bugs, I've mastered hot-keys and added a few plug-ins. I've leaned back and relaxed in the developer easy chair.

Questions

So it is at this point I start to ask myself questions: Do I need to upgrade just to stay afresh? Do I need to learn a new tool set? Should I start over with something else or is there enough work in my area of expertise to keep on with what I'm doing? Will technology shift enough that my skill set will be obsolete in a few years? Or can I fill a programming niche long enough to last the rest of my career?

When I attended the RAD Studio XE2 World Tour in 2011, I got excited about what I saw, but when I got back to my projects and looked at my client requests, I didn't think my customers cared to see their grids on a rotating globe or were interested in replacing all their Windows computers with Macs or (eventually) touch-typing on a hand-held to generate a report of last month's sales. Perhaps I have boring customers. Or perhaps I need new customers. (Perhaps those demos were beyond the typical customer--although they were fun to watch!)

Don't Stand Still

I know that technology advances at a rapid pace and if you don't keep up, you get left behind very quickly. That's one reason I've upgraded through the years--even when I didn't really have to. My applications could probably still be written in Delphi 2007 or even Delphi 7 and my customers would not care. They haven't needed cross-platform capabilities. They haven't needed high-end graphics. They didn't even really need Unicode capabilities (but I gave it to them anyway).

But one thing I know is that when customers DO want change, they want it NOW and the developer needs to be ready for that change or they go elsewhere. In other words, you can't stand still technologically and keep a business based on technology relevant for very long. Which is partly why I've kept upgrading through the years. At least up until Delphi 2010.

Which way next?

So in light of all this, I've been watching the industry trends and trying to decide if and when to upgrade my development tools and whether I should continue down the Delphi road or if a new direction is in order. On one hand, my current applications are very solid Windows 32-bit applications utilizing a client-server database over the internet, printing reports, providing flexible grids for the end user, and generally satisfying the current business needs of my clients. Do they need 64-bit? Not really. Would they like snazzy graphics? No, they're just interested in numbers. Can they fit their reports on a smart phone? Not a chance--I've used Arial Narrow font in landscape mode as it is for some of them. So why rock the boat?

There are trends that cannot be denied. New Windows computers will come with Windows 8 and along with that will be expectations of some sort of information showing up on a live tile. And as much as I hate to admit it, there are already reports of iPads sneaking into offices and I've been asked if the program will work on one of those devices. And I remember a suggestion a year or so ago that it might be nice if their customers could check the status of orders and shipments over the web.

Cross-platform is inevitable

The suggestions above are hints that I need to pay attention to in order to continue serving my clientele professionally in the long run. The trend toward accessing data from nearly any device at any time needs to be the primary focus of software developers building business applications today. There are, of course, limitations to what small companies can do so careful consideration of development tools is more important now than ever before.

For a long time, the choice for me was clear: I have experience with Delphi, it's a good language that keeps up with productivity enhancements found in other tool sets, it resides on the most ubiquitous business platform in the world, and has not only a long history but a promising future. Many of those aspects are still true, but it's not such a clear winner anymore. If I need to support other platforms like the web, iPad, and Windows 8 other than just standard Windows desktop applications, I have to consider a cross-platform tool. Sure, HTML 5 is great, but there are many reasons to develop native applications if at all possible.

Muddy Waters

There are many new development tools and languages emerging that aim to take application development to the next level--that level being the support of more than a single platform. I tend to shy away from the concept of an "app" being little more than a web page, even it it does utilize the latest tags in HTML5. So that narrows my search a little. The ones I've found so far base themselves either in a Java or C# languages. I'm not opposed to the terse syntax at all and may even relish the change, but it does present the obstacle of time to get up to speed.

Obviously, my current development environment, Delphi, is branching to other platforms with the addition of FireMonkey. But it's a little shaky to see major functionality pulled out of a product after only the first release. What if the company decides to change gears again? Will I need to redo a bunch of work that had depended on certain functionality? The question of quality comes up as well. My recent experience with the much-hyped HTML5 Builder was highly discouraging and seriously damaged my confidence in the quality of development tools from Embarcadero. This has cast a shadow on how viable are promises of mobile tools the company plans to put out this year.

Choices, Choices

I guess the good part is that there are always choices. The nerve-wracking part is the concern that time and money spent will run into a dead end. Perhaps a large company can absorb those types of costs, but I can't. This, combined with the experience I have in Delphi, the third-party libraries, and community of developers I'm already familiar with has me leaning heavily toward continuing on with my current environment. (Another factor influencing me is the current offer of 20% off for RAD Studio!)

Who's to say a new tool set won't have problems? Or that the company won't change direction after a couple of versions? What does my experience with HTML5 Builder have to do with Delphi, a completely different product and one into which the company pours significantly more resources?

I would be very interested to hear opinions in the comments below. Many such discussions have already appeared in newsgroups and forums around the internet. One good article with several comments appeared just a few weeks ago and it's interesting to read about the distinction between true natively compiled apps and ones that are just wrappers around an HTML5 page or ride on a JVM of some sort. I really like the approach FireMonkey has taken to provide native controls (or at least "pixel-perfect" representations) where possible stemming from one code-base. It really could be the developer force multiplier they tout (but not necessarily for the product the phrase is currently associated with).

A big part of me really wants to believe in Delphi and continue on the development path that is so familiar and productive. But is that just because I naturally shy away from change? Or is it really the most cost-effective and best long-term decision?