Your reviewer found some newsgroup gems:
Disturbing Trend:
"I've been searching for a new gig for several weeks now and have interviewed with several companies. Every company I've interviewed with has intentions of moving away from Delphi. This is a very disturbing trend.
When I ask why, invariably the perception is that Delphi is old and out dated. A company today told me that it was going to C# because "upgrading its Delphi 5 app to a later version would be too much trouble". It is willing to rewrite its software in another language rather than upgrade!
How do we change this perception?"
Lajos writes:
I don't think so. At the moment in the USA I'm afraid it's more hard to find any Delphi job. I'm looking for 4 month without any luck.
In some job postings there is a Delphi as a language they need a developer with a Delphi skill enough just to make some changes. But most of time Delphi is just a legacy product they did and moved to C#.
Mr David writes:
What makes you think the perception is wrong?
If you look at history for this past decade, the Borland (Delphi/C++ Builder VCL products) have lagged behind their major competitor, Microsoft, by months, often years.
They 'owned' the C++ market prior to C++ Builder, but then gave away compatibility (and the ability to write drivers, etc.) when they made the VCL switch to C++ Builder. They still haven't made it possible use C++ Builder stuff in Delphi, which means that there C++ product is essentially a 'stub' product.
The whole 'Delphi.NET' stuff showed how impossible it was going to be to keep pace with MS, especially on their own turf. It finally became obvious even to Borland, and they terminated it.
The fact that they are so far behind on the 64-bit curve shows that they are continuing that trend, and the fact that documentation is still so poor (let alone in comparison to the MS offerings) means that there is no way to get new folks reasonably involved in the product.
If I were a software manager, looking at a completely subjective breakdown of doing a re-write of the software (for any of several ancillary reasons, such as new features of the operating systems, larger memory needs, new GUI features, etc.), then the evaluation of doing a re-write in C# vs. doing an upgrade/add-on in Delphi, looking at who I think will be keeping up with technology for the NEXT decade, the record of reliability/support for the product, etc., I'd be hard-pressed to argue that a company should stay with Delphi.
Embarcadero really hasn't done much to fix this, either, and I do understand that they're living with the baggage that Borland left behind, but that is part of what they bought when they bought the product line.
Here's one aspect of how things could have been 'better' over the years:
-- I don't know how much "catch-up" they can do from this point, but hopefully you'll get the drift.
1. Embarcadero should be their own third-party vendor (at least for many things). Folks argue that they can't possibly lower the price of the product, they need the revenue stream. I would argue that I spend as much, or more, on third-party tools as I do on the basic product itself. With the loss of TurboPower, for example, there was a market for (at least maintaining/updating) that type of product line. I have/use the TMS line of products, but the documentation is HORRID (arguably worse than Delphi, which is saying something). I use madExcept, some scheduling tools, charting tools, etc. If Embarcadero LOWERED the price of the main tool, and charged for some 'additional modules' (i.e., third-party add-ons), that would be a significant revenue stream.
2. Documentation. This means getting some books out, or re-issuing some of the old ones (buy the @^!*# rights from some of the authors, for heavens' sake, and re-issue them as free PDF files, if nothing else). Get the help system working, even if it means doing one from scratch. Get the samples updated/working, etc. Do a WHOLE LOT of white papers, 'how to' guides, upgrading guides, etc.
3. Do better with the quality assurance/beta tests. Lots of ways this can be handled, but the current methods simply aren't working very well. Just look at how poorly the 'update' functions work in your OWN PRODUCT -- you can't even tell if product is current, you often have to manually download updates, installation procedures fail, etc.
4. Get rid of the 'product activation' crap, and go back to the simpler methods of licensing. I'm not going to re-argue the whole activation/licensing thing right now, but I am absolutely convinced that this stuff provides no real benefit overall for most software. I, and most folks I know, will actively shy away from using products that require this, or finding methods to subvert it. It just creates problems for the 'honest' user, and doesn't really discourage the dishonest ones for more than five minutes. That's my short list...
:)
Disturbing Trend:
"I've been searching for a new gig for several weeks now and have interviewed with several companies. Every company I've interviewed with has intentions of moving away from Delphi. This is a very disturbing trend.
When I ask why, invariably the perception is that Delphi is old and out dated. A company today told me that it was going to C# because "upgrading its Delphi 5 app to a later version would be too much trouble". It is willing to rewrite its software in another language rather than upgrade!
How do we change this perception?"
Lajos writes:
I don't think so. At the moment in the USA I'm afraid it's more hard to find any Delphi job. I'm looking for 4 month without any luck.
In some job postings there is a Delphi as a language they need a developer with a Delphi skill enough just to make some changes. But most of time Delphi is just a legacy product they did and moved to C#.
Mr David writes:
What makes you think the perception is wrong?
If you look at history for this past decade, the Borland (Delphi/C++ Builder VCL products) have lagged behind their major competitor, Microsoft, by months, often years.
They 'owned' the C++ market prior to C++ Builder, but then gave away compatibility (and the ability to write drivers, etc.) when they made the VCL switch to C++ Builder. They still haven't made it possible use C++ Builder stuff in Delphi, which means that there C++ product is essentially a 'stub' product.
The whole 'Delphi.NET' stuff showed how impossible it was going to be to keep pace with MS, especially on their own turf. It finally became obvious even to Borland, and they terminated it.
The fact that they are so far behind on the 64-bit curve shows that they are continuing that trend, and the fact that documentation is still so poor (let alone in comparison to the MS offerings) means that there is no way to get new folks reasonably involved in the product.
If I were a software manager, looking at a completely subjective breakdown of doing a re-write of the software (for any of several ancillary reasons, such as new features of the operating systems, larger memory needs, new GUI features, etc.), then the evaluation of doing a re-write in C# vs. doing an upgrade/add-on in Delphi, looking at who I think will be keeping up with technology for the NEXT decade, the record of reliability/support for the product, etc., I'd be hard-pressed to argue that a company should stay with Delphi.
Embarcadero really hasn't done much to fix this, either, and I do understand that they're living with the baggage that Borland left behind, but that is part of what they bought when they bought the product line.
Here's one aspect of how things could have been 'better' over the years:
-- I don't know how much "catch-up" they can do from this point, but hopefully you'll get the drift.
1. Embarcadero should be their own third-party vendor (at least for many things). Folks argue that they can't possibly lower the price of the product, they need the revenue stream. I would argue that I spend as much, or more, on third-party tools as I do on the basic product itself. With the loss of TurboPower, for example, there was a market for (at least maintaining/updating) that type of product line. I have/use the TMS line of products, but the documentation is HORRID (arguably worse than Delphi, which is saying something). I use madExcept, some scheduling tools, charting tools, etc. If Embarcadero LOWERED the price of the main tool, and charged for some 'additional modules' (i.e., third-party add-ons), that would be a significant revenue stream.
2. Documentation. This means getting some books out, or re-issuing some of the old ones (buy the @^!*# rights from some of the authors, for heavens' sake, and re-issue them as free PDF files, if nothing else). Get the help system working, even if it means doing one from scratch. Get the samples updated/working, etc. Do a WHOLE LOT of white papers, 'how to' guides, upgrading guides, etc.
3. Do better with the quality assurance/beta tests. Lots of ways this can be handled, but the current methods simply aren't working very well. Just look at how poorly the 'update' functions work in your OWN PRODUCT -- you can't even tell if product is current, you often have to manually download updates, installation procedures fail, etc.
4. Get rid of the 'product activation' crap, and go back to the simpler methods of licensing. I'm not going to re-argue the whole activation/licensing thing right now, but I am absolutely convinced that this stuff provides no real benefit overall for most software. I, and most folks I know, will actively shy away from using products that require this, or finding methods to subvert it. It just creates problems for the 'honest' user, and doesn't really discourage the dishonest ones for more than five minutes. That's my short list...
:)
1 comment:
Delphi _is_ old and outdated. Simple fact. A one point in time COBOL was the top development language, now it's not. Technology moves on, and as a software developer you need to be open to move with the times.
Also the guy who designed Delphi, moved to Microsoft and designed C#
MS has clear goals for the Visual Studio platform, while Embarcadero, can't seem to get it together. They just 'fired' the R&D manager for the Delphi product line. To be honest, I really have doubts if there will be another big release of the Delphi development system.
In terms of re-writting versus upgrading. It is taking just as long to upgrade D5 apps to D2010, as it takes to rewrite the whole thing again in C#. The reasons included poor 3rd party tool support (the vendors have moved over to C#), to no/bad design documentation.
Our company is moving over to C#, rewriting our applications, as we also get to re-design them. Our policy is an new development is done in C#.
Move with the times, or die. We lost a developer who refused to move to C#, he was out of work for a whole year, and had to take about 200 miles away. (One of the reasons that he left, is because he refused to travel 40 miles to the new office)
Post a Comment