Why upgrade?

[David Schwartz 426]

If you're working with 32-bit apps and they work perfectly, and you're not using any of the new stuff being added to the Delphi ecosystem at it's fringes, and upper management asks why you need to upgrade everything to work with the latest Delphi release, what do you tell them?

 

The code here was built in 2003 - 2011. It's stable, bug-free (aside from an occasional memory leak), and does not gain anything by being re-built on a newer version of the compiler.

 

They really don't want to do any more work in Delphi, other than necessary maintenance. Their intention is to move all software over to C#. I don't know why, they just think it's a "better platform", and I don't really have anything to argue with. It's the same story I've been hearing for a decade now from pretty much everyplace I've worked.

[Uwe Raabe 2057]

1 hour ago, David Schwartz said:

Their intention is to move all software over to C#.

Experience shows that this usually never happens - and if, it will not happen in the expected time frame, cost and functionality. The first barrier is usually the lack of documentation what the Delphi software does, how it does it and why it does it that way.

 

I personally have seen a couple of such endeavors going down the drain. They could as well have burned the money in the first place.

[Sherlock 663]

I personally know of two companies in my field of work (medical software), that have killed themselves over the "simple" task of moving from "some old outdated" language to C#. Both companies have enjoyed the questionable pleasure of being tutored by MS consultants. What everybody involved forgot, is the amount of customizing that went into the software for some special really needy customers - customizing, that went unnoticed or at least undocumented. So a bunch of features, and I mean a really big bunch, did not end up in the painfully created C# versions of their software, and the customers simply left. Because it got more expensive as well. And then from the customers POV it's just simple math: less features + more cost = bye bye.

 

Now both of those companies have been bought for a penny and a dime by the one I was in at the time. And constant rumors of the need to move to C# with our divisions software kept rolling around...but never became true (someone at the top must have learned something). New projects where done in other languages, but that is totally OK.

[Vandrovnik 214]

When you are up-to-date with Delphi, it is easier to accomodate the software to new demands (such as was UTF or HDPI in the past, may be 64 bit in the future - hard to say how many years 32bit apps will be supported, new encryptions etc).

 

Move software to another language will cost a lot of money and time (and new bugs and old features missing in the beginning).

[Fr0sT.Brutal 900]

As a single developer, I sometimes rewrite my projects to newer technologies without a significant improvement just to keep myself up-to-date. But I can't understand why business decides to rewrite a working and tested project written on "good old lang A" from scratch using a "brand new shining lang B". Especially considering that "lang A" is pretty alive and developing. Geek coders sometimes tend to rewrite things just because existing stuff uses a language, libs or even a license they dislike but a company with customers shouldn't be such geek.

[Dmitry Arefiev 101]

Beside what @Vandrovnik said,  Delphi with each one new version is getting more and more "green" (in the sense of Greenpeace, or energy class). What in past consumed N CPU cycles, now may consume less or much less. Want to make the World more green ? Upgrade your Delphi 🙂

PS: Of course, this is questionable statement. But it is true in many Delphi areas ...

[Anders Melander 1782]

10 hours ago, David Schwartz said:

If you're working with 32-bit apps and they work perfectly, and you're not using any of the new stuff being added to the Delphi ecosystem at it's fringes, and upper management asks why you need to upgrade everything to work with the latest Delphi release, what do you tell them?

Tell them you agree.

If the applications are in maintenance mode then I don't see any reason to upgrade, potentially introducing new problems with no benefit to the company or its customers.

 

Keeping Delphi, and 3rd party libraries, up to date is a costly investment and unless a product is being actively developed that investment might not yield a sensible return.

 

 

9 hours ago, Uwe Raabe said:

I personally have seen a couple of such endeavors going down the drain. They could as well have burned the money in the first place.

Whenever someone mentions the idea of a completely rewriting something from scratch I simply respond "Like Netscape?"

 

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Quote

We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

 

I've been through a couple of successful complete rewrites myself, but they were architectural rewrites that were done incrementally. We basically refactored everything one tiny thing at a time until we finally arrived at the destination, many years later. And we stayed with Delphi. An incremental rewrite isn't really possible when you're replacing the platform.

Edited February 25, 2020 by Anders Melander
added Spolsky quote

[David Schwartz 426]

7 hours ago, Anders Melander said:

[quoting Joel Spolsky]: We’re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We’re not excited by incremental renovation: tinkering, improving, planting flower beds.

While I find this interesting, I don't agree with him, although I get where he's coming from. My experience is that most programmers are heavily left-brained and incapable of dealing with things at a more abstract level. I've worked with far too many who simply cannot discuss new ideas without being rooted in concrete examples. There are places that end up hiring folks who are capable of more abstract thinking, and places that don't; I think it's more of a reflection of the people who are doing the interviewing and making hiring decisions.

It's like musicians who can play virtually any music like a virtuoso just by reading sheet music, but they can't improvise if their life depended on it. I can make anything sound musical and pretty much improvise everything; I cannot stand reading music. Experienced musicians think I'm a pretty odd duck in that respect. Similarly, I can have very abstract discussions with people, although there are those who can't follow what I'm saying unless I can give them very concrete examples to follow. It can be quite exhausting.

 

I spent several years at a place that had a nice balance. The next place I landed on a project where the core developers were from Bell Labs, and they certainly attracted abstract thinkers, but those who migrated in from other parts of the company were not so much. Another nearby division had a bunch of ex-college professors working there. While you'd think they'd be fairly good architects, my interactions with them left me wondering how they ever got hired. They argued with such ferocious tunnel-vision about microscopic details that it was nearly impossible to get anywhere with them.

 

I've met people who have tried and tried to write components for Delphi but just can't wrap their head around it. Others see very little difference between a unit that's used in a program and turning it into a component.

 

 

Edited February 25, 2020 by David Schwartz

[Anders Melander 1782]

1 minute ago, David Schwartz said:

My experience is that most programmers are heavily left-brained and incapable of dealing with things at a more abstract level.

Yes, we've had that discussion already. No thanks.

[Remy Lebeau 1393]

19 hours ago, David Schwartz said:

If you're working with 32-bit apps and they work perfectly, and you're not using any of the new stuff being added to the Delphi ecosystem at it's fringes, and upper management asks why you need to upgrade everything to work with the latest Delphi release, what do you tell them?

In my company, I still use C++Builder 6 every single day.  Our team WANTED to upgrade over the years, but upper management always said no for one reason or another.  Either the IDE was too buggy, or the price was too high (both for the IDE, and for licensing 3rd party libraries we use), or the new features weren't beneficial enough to our work.  Our company was bought by a competitor a few years ago and I'm the last remaining legacy developer, maintaining our software which is now on life-support pending its final end-of-life at the end of this year.

Quote

They really don't want to do any more work in Delphi, other than necessary maintenance. Their intention is to move all software over to C#. I don't know why, they just think it's a "better platform", and I don't really have anything to argue with. It's the same story I've been hearing for a decade now from pretty much everyplace I've worked.

Yeah, our company made that move years ago, writing new software in C# and maintaining existing software in C++.  Our C# products don't hold a candle to our C++ software.  Our C++ software took months to release to market and takes days to fix (usually), but our C# software took years to release to market and takes weeks/months to fix.  The C# code is just so much more ugly and overly complex compared to the C++ code.  At the time, I was glad to have never had to work on the C# products, but now I'm last man standing who can ever work on it, so I'm having to learn about it as I go.

 

Edited February 25, 2020 by Remy Lebeau

[Darian Miller 361]

19 hours ago, David Schwartz said:

If you're working with 32-bit apps and they work perfectly, and you're not using any of the new stuff being added to the Delphi ecosystem at it's fringes, and upper management asks why you need to upgrade everything to work with the latest Delphi release, what do you tell them?

 

The code here was built in 2003 - 2011. It's stable, bug-free (aside from an occasional memory leak), and does not gain anything by being re-built on a newer version of the compiler.

 

They really don't want to do any more work in Delphi, other than necessary maintenance. Their intention is to move all software over to C#. I don't know why, they just think it's a "better platform", and I don't really have anything to argue with. It's the same story I've been hearing for a decade now from pretty much everyplace I've worked.

 

For what it's worth, here's a few different responses:

 

 

One answer is keeping up to date with changes to Microsoft Windows... for example HighDPI support.  Does your software work well with Windows 10 high dpi systems?  Delphi is getting much better with this particular issue.  Hopefully 10.4 finally fixes some of the issues with VCL Styles and High DPI.

 

Another answer is compliance related - some compliance certifications require your tooling be kept up to date with all available patches/updates. If you aren't under third party audits, this is less of an issue but for security in general keeping current is wise.  (Do you have the buffer overflow fix for Delphi in place?)

 

Another answer is business risk / insurance related - It may bite you later on any future insurance claims that you knew you were out of date but didn't upgrade to fix any potential problems.  

 

Are you going to milk this thing as it is until it dies, or are you ever going to add new features?  If you are going to add features, staying current may make future features easier, especially keeping up with fast changing technologies like AWS/Azure.   

 

If you are using any third party components, eventually they will drop support for older versions of Delphi.  You have to assume most of the new activity in third party components surround the new releases.  With more and more new language features becoming available (like inline variables) that devs really like to use which aren't backwards compatible, the rate of third party components dropping support for old versions will probably increase over the next few years.  This is obviously one of the prime goals of Embarcadero - and they will keep hammering at.  It's in their best interest to introduce new non-backwards compatible language features and this approach will succeed over time.

 

Finally, the longer you wait, the harder it becomes to ever bring it back up to date.  It's just delaying the cost today for higher costs tomorrow.  If they are in it for the long term, they should act like it.

 

 

If you are a one or two-man shop then it's certainly much harder to justify the ongoing costs due to the ever increasing price (which I assume will keep getting worse), but if you are making a decent living with the Delphi products then it only makes sense to keep them current.

 

 

[Stefan Glienke 2002]

On 2/25/2020 at 9:21 AM, Dmitry Arefiev said:

Beside what @Vandrovnik said,  Delphi with each one new version is getting more and more "green" (in the sense of Greenpeace, or energy class). What in past consumed N CPU cycles, now may consume less or much less. Want to make the World more green ? Upgrade your Delphi 🙂

PS: Of course, this is questionable statement. But it is true in many Delphi areas ...

Data please or I call that fake news

[dummzeuch 1505]

1 hour ago, Stefan Glienke said:

Data please or I call that fake news

Actually when I did some performance comparisons between Delphi 2007 and 10.2 with the same code and the same compiler settings, I got some noticeable improvements (yes I did timings).

That's one particular program though and it is doing heavy graphics manipulation with mostly integer arithmetics, but still, it's evidence that the compiler was indeed improved since 2007. I can't say anything about improvements over the last few releases though. And the IDE is definitely eating more CPU in every new release.

[Uwe Raabe 2057]

1 hour ago, Stefan Glienke said:

Data please or I call that fake news

Due to the sluggish behavior of the themed IDE in some of the later versions I decided to buy a new PC. It turned out that the overall power consumption of the new PC is lower than that of the previous one even with a significantly better performance. 

[lisichkin_alexander 0]

I can make a few assumptions:
1. A 32-bit application works with a database. and for some reason You need to process a large amount of information not on the server, but on the client and the amount of data exceeds 3GB of memory.
2. You want to write a dll library for a 64-bit application (Extended stored procedure)

3....

This is only a 32 to 64 bit transition

[David Heffernan 2345]

Sounds like management are right here. Why should they spend money on upgrading? And it's probably less the license costs but mote the time cost of the staff migrating code and tools.

[David Schwartz 426]

my predecessor spent a while preparing to migrate from Tokyo to Rio, but left before it was finished.

 

I've been asked how long it will take to finish.

 

My reply was, "I don't see why it's necessary." 

 

The only reason they can come up with is, "Because [predecessor] believed it was important and he spent a lot of time preparing for it."

 

I'm not able to find any particular benefit of upgrading since nothing new in Rio gives us anything we need. We're not about to refactor gobs of code just to take advantage of some new syntactical geegaws. 

[dummzeuch 1505]

7 hours ago, David Schwartz said:

refactor gobs of code just to take advantage of some new syntactical geegaws. 

I agree, mostly, at least when it comes to upgrading from 10.2 to 10.3. The disadvantages of the unstable IDE offset the advantages of new language and IDE features by far.

 

But I would have upgraded from 2007 to any XE version (up to 10.2) if it weren't for the subtle bugs the Unicode transition is likely to bring to code that isn't prepared for it (we still have code that uses strings as buffers for binary data, even though I have cleaned it up a lot). There are of course no unit tests for this legacy code, and on top of that they are difficult to write, because they usually rely on some hardware to communicate with.

And just to add more fun, this code must run on Windows XP, which is no longer officially supported by the RTL and even less by the IDE (did anybody try to install recent Delphi versions on XP? I would be interested in your findings). That is a major stumbling block(?) right now.

[Fr0sT.Brutal 900]

7 hours ago, David Schwartz said:

my predecessor spent a while preparing to migrate from Tokyo to Rio, but left before it was finished.

Why it took him so long? These versions are very similar. I could understand complexity of D7=>D2009 migration due to Unicode; x32=>x64 is even easier in most cases. But 10.2=>10.3?

[Uwe Raabe 2057]

 

7 hours ago, David Schwartz said:

I'm not able to find any particular benefit of upgrading since nothing new in Rio gives us anything we need

You might be forced to reconsider this statement when your customers are more and more using high dpi configurations and criticize the visual quality of your application. While the IDE ist still not ready for prime time in 10.3.3, most of the applications can be tweaked to behave well in these situations. The upcoming 10.4 may be right better with that. Laying out this transition now may give you some advantage when demands are rising and management expects a quick fix (No, problem. You can have your Delphi update, but we have to deliver next week!).

[Sherlock 663]

When given the option to upgrade: Upgrade. Every single version. The individual steps between versions are not that big. We will most likely not be facing a brute like the Unicode disaster (in my eyes) like back in the day.

@David Schwartz: I seriously have to wonder, what needs to be done between Tokyo and Rio. In my (albeit not very broad) experience there should be nothing to do at all, except when using FMX, but then FMX forces to update anyway.

 

Sherlock

[David Heffernan 2345]

It costs me time and money to upgrade and for now I'm missing nothing by sticking to XE7. But that's just me. Different users will have different drivers.

 

Nobody can made a blanket statement like 

2 hours ago, Sherlock said:

When given the option to upgrade: Upgrade. Every single version.

 

[Anders Melander 1782]

2 hours ago, Sherlock said:

When given the option to upgrade: Upgrade. Every single version.

You must love the Windows Update policy in Windows 10.

[Anders Melander 1782]

2 hours ago, Uwe Raabe said:

You might be forced to reconsider this statement when your customers are more and more using high dpi configurations and criticize the visual quality of your application.

Windows does a better job of making old applications behave well under high DPI than the VCL has so far managed.

I would prefer to have the UI consistently scaled than having some parts support high DPI, some parts scaled and some messed up.

[Uwe Raabe 2057]

6 minutes ago, Anders Melander said:

Windows does a better job of making old applications behave well under high DPI than the VCL has so far managed.

That may depend on the actual case. The Windows scaling is fine as long as you have images that look ok when enlarged significantly. Usually you have not. Also CAD like applications are not so good candidates.