You ARE Paying for Bug Fixes - Do you like it?

I got notified today again about the IDE memory consumption issue (RSP-9568) I continually encounter even in XE4, although it seems to be more severe in later versions.  The Atlassian graph is very telling.  It seems EMBT is not even treading water, let alone making progress addressing quality issues.

Issues: 239 created and 202 resolved

Issues: 239 created and 202 resolved

So without buying the latest release, when or more to the point if issues like the Out of Memory problem actually get fixed, do you really think you will get an update for free?  No you will have to buy the latest release with all the new bugs.

Effectively you are paying for the new bugs at the same time as you pay for the old ones to get fixed (if they do), not to mention the cost in terms of lost productivity, component upgrades, and installation time.

With .NET Native coming, soon Delphi will not even be able to claim to be king of the hill in terms of ease of deployment and fast startup times…we certainly cannot claim to have a superior IDE in terms of stability or productivity even it appears with the addition of Castalia.

26 Responses to “You ARE Paying for Bug Fixes - Do you like it?”

  1. Stefan Glienke Says:

    The public JIRA stats are no indicator. They don’t resolve them when they fix their internal counterpart. Or do you think they fixed 200 issues in one day and then did nothing anymore? :)

  2. Markus Ja Says:

    If .Net will become really full native, I think a lot of Delphi folks will move to Oxygene.

  3. Rollo Says:

    Give Fmx a chance, it has great potential.
    I did/do great projects since many years with Delphi/Fmx 5-Xe8.

    I also hate when things doesn’T work as expeced, but isn’T that our everyday job ?
    Go out and fit it …


  4. Theo van den Berg Says:

    I always hope when i pay for something i can REQUIRE or DEMAND the fixes i need. the experience with Embarcadero or predecessors was not very good in the last years.

  5. Sebastian Jänicke Says:

    Regarding Castalia:
    I did not think it would be possible to have more bugs in refactoring than in the Delphi IDE, but Castalia teached me better…
    In Delphi at least I only got an error and refactoring simply did not work.
    Castalia now in XE8 breaks the code, if an error occurs. And it does happen very often.
    1. Castalia extracts a method, makes var parameters, but the values it gives as parameters can be constant values too… so the resulting code does not compile.
    2. Even worse, often it displays an error, and instead of leaving the code unchanged, it inserts the lines, which were selected, for example a few lines obove the source location.
    So the code is simply broken. And undo does not work afterwards.

  6. Bruce McGee Says:

    Oh knock it off.

    I’m paying to stay current and I like it just fine.

  7. LDS Says:

    Sure, there are people who pay to be fustigated… if you like it…
    Others don’t and would like to pay for better products… so, knock it off you too.

  8. Petar G Says:

    Btw, I think Embarcadero should pay bug-finders or at least give them product discounts/free upgrades. This may be a great stimulus for more bug-free RAD versions…

  9. Larry Hengen Says:


    Good point. I suppose I would have to look at a longer time period for it to make any sense and of course that is not available.

  10. Tristan Marlow Says:

    Why would you not run the latest and expect to pay a “subscription”

    If you had a customer on version 1.1, the bug was fixed in version 1.5 would you go back and fix it in version 1.1 or upgrade them to 1.5?

    We use a subscription for our software, everyone can and is upgrade.

  11. Dalija Prasnikar Says:

    @Stefan @Larry If you want longer time period statistic, you can have it.

    QP was introduced with XE7 release.

    If you go to you will see number of currently opened and resolved/closed issues. So statistics for last 7 months look like this: 1081 open issues - 77%, 297 + 20 resolved/closed - 23%

  12. Michael Says:

    Wait… Delphi claims fast startup times? Am I the only one getting a splash screen for ~30 seconds before the IDE even appears?

  13. Wouter Says:

    In theory, I don’t really care if code gets compiled for specific hardware or that it compiles to some abstraction of it, like with Java or C#.

    However, there are now more incompatible variations of these virtual targets than there are hardware architectures, so it still makes sense to target hardware. For me that’s mostly because of compatibility.

    Send a win32 app to somebody, and there is a 95% chance that it works without having to install extra stuff. Send a dotnet or jar program, and chances are high that the receiver is going to have problems running it.

    Is dotnet native going to produce self-sustaining monolithic executables? If not, then it’s not going to convince many Delphi users to suddenly switch over if they didn’t do it yet.

  14. Stefan Glienke Says:

    @Wouter: yes it is - I recommend watching this video to understand their approach:

  15. Leonardo Herrera Says:

    The only reason I didn’t want to use .NET is that it is too easily decompilable. My own software sells because it can do something few can (it can generate some legal documents for my country tax office that are tricky to do) and I sell with a license that allows its use for one company.

    If it was a .NET program, your nephew could get ILSpy, decompile it, change the validation logic, and recompile the program.

    With a Win32 app, at least you need to contact a somewhat skilled hacker to create a crack for it. It is not impossible but hardly worth the hassle, so they leave me alone.

    If they get a way to make real native apps with .NET I’ll definitely consider the move. I’m not optimistic, because reflection is an important part of the framework.

    So, for the time being, and until I move to the “cloud” (hate that term) I’ll keep using Delphi (I love it, but it is getting harder to stay loyal.)

    (BTW, I’ve never had the “out of memory” problem…)

  16. Stefan Glienke Says:

    Leonardo Herrera: you did realize that .NET native produces a win32 (or whatever platform you target) binary that does not contain any IL but machine code just as any Delphi or C/C++ binary, yes?

  17. Neal Campbell Says:

    The statistics do not prove your point that they are not even treading water. Pure quantities do not mean anything other than the efficiency of their testing organization, the adherence to recording bugs and their adherence to changing status in their problem management database.

    Would you rather that the testers do not test as well or record fewer problems so the numbers do better than tread water?

    I personally would rather reward those that create the error reports as well as the ones that close them, and not promote bad behavior by citing numbers like these to prove lack of quality.

  18. Michael Says:

    @Stefan G. That cannot convince me at all. That’s the advantage ob meta-data stored together with executable and reused as a compiler input. A compiler simply takes an input according to a grammar and generates an output. Indeed after 20 years the return to the original idea of the C# language. Amazing at all but honestly … that’s about having to cope with legacy in another way. Similar to COBOL when the source was lost in the Y2K ‘crisis’.

    In practice unsafe code can often be found in almost every C# program. There is lots of magic going on anyway.

    I think MS will work on an clean C# compiler generating binary code in the end and they will very likely end up offering different compiler for different platforms. Topspeed did have one backend for ‘various’ languages … That approach does make sense indeed.

    I don’t know if MS really do think of apps - as far as I have understood they talked about ‘non visual’ when it came to cross platform. But we will see.

  19. Frank S. Says:

    From my almost 10 reported bugs in JIRA was fewer than one fixed. (the smallest and least important … a forgotten Property, 7 years ago)

    Otherwise, I had been all FMX tests need to set some time since I came across serious bugs.

  20. Larry Hengen Says:


    Delphi compiled EXEs are known for fast start up times. THE IDE itself, especially in later verisons with all the piracy protection checks, is VERY slow. In fact, it is much like starting a .NET app in that you double click and wonder if the app has been launched since it takes at least a second on an SSD before the splash screen appears.

  21. LDS Says:

    “If you had a customer on version 1.1, the bug was fixed in version 1.5 would you go back and fix it in version 1.1 or upgrade them to 1.5?”

    If version 1.1 is still officially supported (paid or non paid…) yes, I go back and fix it in 1.1. I follow a development model that makes it as easier as possible.
    For many reason, a customer may not want to upgrade everytime you fix a bug (and add new ones), because an upgrade of a complex application may be complex as well. It may mean to update other components, databases schemas, OS and database as well if the new release doesn’t support some older ones, etc. etc. Multiply it maybe for some thousands of clients systems…
    Sure, some small utilities can be simply upgraded to the latest release - but why do you believe software like Ubuntu, etc. has now LTS - Long Term Support - releases? Exactly to be sure you’re not forced to upgrade to a new releases and its changes if you don’t need to.
    There is no “one model fits all”. I prefer to give my customer options so they can choose what they need - and stay customers of mine - instead of forcing them to adopt a model that works well only for me.
    Frankly, the subscription model looks designed to put the burden and the risks of new release on customers instead of the “mighty shareholder”. Right now you can easily skip and not pay for botched releases, and the shareholders bear the result of missed revenues. Now no longer, you pay anyway.
    As a customer, I become very tempted to look for alternatives. And someone thought that Microsoft document formats/protocols lock-in was bad…

  22. Wilfred Oluoch Says:

    EMBT: One version of Delphi per year. and make it rock solid. Bug fixes via updates for 12 months after the release and leading up to the next big release.

  23. Matthew Kinney Says:

    I just got back from Microsoft Ignite–.NET IS going native and the performance increase is significant and I have first hand experience with it. .NET 2015 is the biggest .NET release in 10 years (since 2.0) and Visual Studio 2015 is absolutely amazing as far as programmer productivity. The things you can do with the Roslyn compiler are really something else and I think it is only a matter of time before Microsoft buys Xamarin to really have an amazing cross platform solution.

    Also, you will have the ability to produce single-file EXEs and not have to distribute the whole .NET framework, etc. — I commented “just like Delphi!”, but the cool thing is it doesn’t just cram the whole framework into your EXE but is smart enough to only include the parts of the framework you call or use (something FMX could certainly learn a thing or two about).

    I love Delphi and still use it daily, but EMB just doesn’t have the resources to compete with what is coming out in the modern software development world. NOW–if they scrapped the stubborn headed “must have our own IDE” and just plugged Delphi into Visual Studio 2015 (doable as it is completely extensible) and focused on the actual language itself as compiler quality…

  24. Ron Says:

    @Matthew Kinney
    Its remains to be seen if Roslyn is any better or faster then C++/object pascal code. It helps with code completion and code analyses. Its open source so maybe the EMB team can pick up a few things there. Just like the parallel lib and generics. Linq first :-)

    The strategy with Xamarin is, I think, mostly about getting and staying devs on VS. Just to get dev developing at least for Windows X when they create something for android/IOS. I build a few apps with Xamarin via Forms and via the classic routes. Forms is a buggy immature product (for example: IF you want something that is not available in Forms (90% you will) you can also add the classic route screens/code. Which is tedious etc but this another discussion.

    Did you know that MS Office and a lot more MS products are not build in .NET but in C++? They run on IOS and android too. Don’t no how they do that. Not with Xamarin. Don’t think Xamarin get bought. That’s like supporting Android. They do it the other way around. You can run android apps on W10 via some kind of VM and you can run IOS on W10 via recompilation (objective c only) according to the demo. Thats the MS strategy. Getting apps to W10. Thats why Silverlight got ‘Freezed’. The SL OOB was true thin cross platform .NET (some namespaces not there, but where mostly redundant) with real perf. But it was eating Windows share.
    Don’t think Xamarin is backed in a few years when W10 become a hit.

    Abandoning the IDE is almost giving away the shop and be completely dependent on MS. The trend is the other way: Cross platform IDE’s are falling from the skies these days, everyone is building one, even MS (hello xamarin). Think about a delphi/c++ builder/appmethod IDE on OSX.

    As a .NET developer I see great potential for the FMX platform. I saw things coming together with XE7 and even better in XE8.

  25. Ron Says:

    One release a year just won’t do in this fast moving Internet age. Apple alone pushes out 4 versions a year.

  26. Eivind Says:

    Peter G, Emb’s problem isn’t that it’s difficult to find bugs; the problem is lack of budget and manpower to fix all the bugs already found for free…

Leave a Reply