The Lengths we will go to for a Bug Fix

May 25th, 2016

For anyone using the Win64 Debugger in DX Seattle, you have probably experienced this little gem:

Debugger is Buggered

Debugger is Buggered

This seems to happen more frequently with multi-threaded applications, and unfortunately is not the only issue with the debugger.  Being unable to step into interfaced method calls which was reported on 12/1/2014 4:49:50 PM (541 days ago) is a real pain for 64 bit development.  Both issues are present in Seattle Update 1 and both are still unresolved with the release of Berlin.

I have been meaning to investigate how to use one of my support incidents to escalate RSP-14144, and apparently I am not alone in wondering how to get the priority changed for bugs to be addressed.  Keith Dopson has offered free meals, accommodations and shuttle service for EMBT to address RSP-13503 which surprisingly EMBT has not been able to duplicate. Kudos to you Keith! I hope it works out as we will all benefit.

Not The Ideal Idera Experience

May 19th, 2016

My DX Seattle installation starting throwing access violations whenever a form was loaded into the IDE last week.  I had started to install Berlin on the same machine, so I wasn’t sure if that or some other installation had triggered this situation.  Having to bounce the IDE every 5 minutes was increasing my frustration level to the point I was about to nuke the whole machine, when I thought I would try a quick google to see if I could find the cause.  I found this thread, so I toggled on Tools - Options - Form Designer - Show Non-Visual Components and it worked!  I decided to search the bug reports only to find it has been fixed in Berlin.

I have an update subscription.  I was not notified that Berlin was released.  I found out from reading posts well before I received a general marketing email on April 20th.  I wasn’t notified that a bug which might affect my product was fixed.  While I can subscribe to individual issues, I do not believe that I can get notifications for all bug fixes for my product edition.  Something Idera might want to look into…

A Case for YAGNI?

May 6th, 2016

I have worked with Delphi for a long time now (since D1), and am embarrassed to say that for the first time today, something occurred to me I have never thought of before.  I was waiting for DX Seattle to finish compiling a rather large project, or more accurately link it.  I was threading some legacy code and wanted to verify my changes could be compiled.  This is a very common usage scenario for Delphi.

It occurred to me that linking the EXE was a complete waste of time, and that link cycles are longer than normal because we are creating a detailed MAP file in our debug configuration.  I could eliminate this file, but we often use it with other tools.  I was thinking I should use Delphi’s Project - Syntax Check menu option instead.  So I tried it, and it ran through all the units in my source path that were referenced in the current project (directly or indirectly).  I thought to myself that the documentation which claims that “an efficient way to verify before compiling that a large project will build correctly” is not exactly accurate.  If it is so efficient, you would think it would be the preferred option to use, and it would have a menu short cut.

A more efficient way to to check for correct syntax is using Project -> Compile because it only re-compiles units that have changed since the last compilation.

So I was thinking, why wouldn’t the Syntax Check option do the same as a Compile, only checking changed files, or why wouldn’t the Compile avoid linking?  Most of the time linking is not necessary and could be performed when you hit F9 or Shift + F9.

The Parsing Problem

May 2nd, 2016

One of the major stumbling blocks Delphi tool developers have to overcome is the parsing problem.  Any add-in that allows re-factoring of code at any level must first parse it accurately enough to provide the additional functionality.  While Visual Studio has a VSIP (Visual Studio Integration Partners) program, EMBT has nothing to my knowledge.  They seem to discourage third party tool developers by not documenting the OpenTools API, or extending it to open up possibilities that are found in other IDEs from other vendors.

I don’t think this necessarily intentional, but the effect it has on the productivity of the IDE is enormous.  Up until the release of XE8 (IIRC) basic code navigation was missing from the IDE.  With the acquisition of Castalia the base product finally had a way to jump to method implementations short of using Ctrl+Shift+ Up/Dn Arrows after finding the method name.  By that time, most everyone was using a combination of GExperts and/or CnPack.

If you look at tools like ReSharper, or CodeRush for C# you will see just how far the Delphi IDE toolset is lagging behind.  Why?  Primarily because as the Object Pascal language has evolved under EMBT (kudos to them for doing so), there has not been a published language specification.  Third party tools reliant on their own parser have been left behind.  I’m not sure about those based on the Castalia parser derived from Martin Waldenburg’s parser.  I assume Castalia has also fallen behind since it’s last update was in October 2011.

Inevitably, some of these tools will no longer parse what is now valid Object Pascal.  I just ran into one today.  A tool that has been in the Delphi space since 2001.  I downloaded Peganza’s Pascal Analyzer and tried to run it on one of our projects to see what it could offer.  It failed in third party code that heavily uses generics (Spring for Delphi) in the Spring.Collections.MultiMaps unit line 49 of my version which reads:

fDictionaryEnumerator: IEnumerator<TPair<TKey, ICollection<TValue>>>;

with the error:

Syntax error type #123 (<) at Spring.Collections.MultiMaps row 49

Code re-factoring and analysis tools are critical for writing Enterprise level applications that must run 24×7.  I wish EMBT would open up the IDE so we could get rid of the spinning hourglass while code is parsed in the main IDE thread, and make the IDE more responsive.  While better in terms of not crashing with “Out of Memory” errors, DX Seattle is slower, still has leaks, and has issues of it’s own with 64 bit debugging.  An IDE needs to be stable, performant, and provide the developer with a rich set of tools for re-factoring their code.  There is much to be done on this front IMHO.  I think, formalizing the language and opening up the internal parser information would go a long way.  Even better, would be open source the IDE and let the community fix it :-)

Temporary Outage

April 22nd, 2016

You may have noticed that my blog has been off line for a while now.  Took me a couple weeks to find the time to rebuild my machine after a hard disk failure.  It’s still not 100%.  Images are not appearing with the blog articles for some reason.  I hope to have that resolved this weekend.

DX Seattle is Unstable with CnWizards

January 15th, 2016

I installed the latest CnPack’s Wizards 1.09.89 a couple days ago and DX Seattle suddenly seemed much slower, sometimes pausing for several seconds before presenting an hour glass and coming back to life.  A few times Windows actually detected it as not responding and prompted if I wanted to Debug or Close Delphi.

Today I uninstalled CnPack and DX Seattle is again responsive.  Too bad, I like a few of their add-ins.  Hopefully a subsequent release will resolve it.

Installers Lie

December 16th, 2015

At work I have an SSD which is only 220 GB so it is almost full almost all of the time.  Gone are the days of lean software deployments, and I am a hoarder when it comes to information.  As a result, I was attempting to install DX Seattle on my SSD and Install Aware told me I had sufficient space after unselecting various features.

After proceeding, Install Aware told me it does not have enough!

In the end I did manage to free enough space to get DX Seattle installed, although it was like playing Russian roulette.  I ended up removing vital components for SQL Server Management studio that I then had to repair.

A Pleasant Development

December 15th, 2015

I recently upgraded to DX Seattle which contains the long awaited (7+ releases) resolution for the “Out of Memory” issue.  I was pleased to see that DX Seattle is now Large Memory Address aware, in addition to using memory more efficiently according to Marco Cantu.

So far, after installing Update 1 with the Modern Style hot fix I have not experienced a single Out of Memory error.  As a result, we are upgrading our licenses for the first time in 3 years even though there is a big push to move the core products to .NET.  If only EMBT would have addressed this earlier, perhaps we wouldn’t be so motivated to move.

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

May 7th, 2015

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.

A Response to Nick Hodges - You will pay for bugs and like it!

April 24th, 2015

I tried to post a comment on Nick’s blog, but for some reason I never got the email for verification of my address so I thought I would respond here.

I find it very interesting that a former EMBT employee still with close ties, would write such a post.  I understand how he drew some of his conclusions, but I think he is mistaken and I hope EMBT does not share the same views.  Understanding the marketplace is very different from software development.

First of all, code quality is more about developer skill, and the processes employed during development and QA. The earlier defects are found the cheaper and easier it is to fix them. The number and age of unresolved bug reports does not speak well to EMBT’s (and their predecessors) concern for code quality. However, the primary driver, as with all things produced by a company, are the decisions made by management.  While no code is perfect, if you accept that it is not possible to produce bug free software then you have lost the incentive to try.

Having “volunteers” go through QC reports says that a company isn’t even willing to pay their staff to properly evaluate bug reports. Having a broken voting system and web QC, as well as an antiquated Windows client that not being maintained speaks volumes about what is important to a company.  Admittedly, the bug tracking systems have finally changed.  It doesn’t seem to have affected the number of fixes for long outstanding issues though. As people we spend our time on what we believe is most important. Same thing for companies.

Allowing half baked (incomplete) or non-working visible things like the panel at the bottom of the object inspector that Marco wrote an add in to remove, Error Insight, and the Refactorings remain in the product for years without fixing them is not only stupid IMHO, but a software development nightmare. Web companies are making money on minimalist applications that satisfies a small need, but does it extremely well. EMBT seems to prefer the old school thinking of a humongous application that does everything under the sun, but does some things very poorly, and taints everything else with the same code smell. They don’t even seem to be willing to consider using the plug in system to provide ‘a la carte’ choices to their customers, or drop existing functionality that is not required to limit their technical debt going forward. What other company has someone external to the company provide bug fixes for their IDE that apparently never get incorporated into the product because Andreas is still churning out IDEFix pack!

Only in an emerging marketplace can you continue to sell flawed products that look good on the surface, but don’t work as well as they should, to be used daily for someone to make their living. Development markets are not emerging ones, nor are they without stiff competition.

Developers are smart people. EMBT is fooling no one with their choices when it comes to resource allocation. Hire cheaper developers around the world to cut costs, focus on emerging markets where quick profits can be made, and increase the cost of the tools by coupling the mobile pack with the core dev tools and charging for each, effectively double dipping, while raising the cost of the product across the board and providing diminishing product quality. Typical of a company acquired to provide profits to it’s purchaser, and not for any ideological reason.

The definition of insanity is doing the same thing over and over expecting a different outcome.  Developers will only continue to buy EMBT licenses or subscriptions as long as they have to in order to support their products, or where their is some advantage (none come to mind right now) because they aren’t insane.  EMBT on the other hand cannot continue indefinitely down this path, unless they want to drive away their user base, or intend on getting as much cash from their users until the bottom falls out, and they close the doors.

Delphi is no longer a bleeding edge tool, even in the mobile space.  It has more competition than ever, and a major challenge with Microsoft/Xamarin/.NET Native and Apple competing in the market place.  One of the reasons for it’s current success is the older user base supporting existing applications built when Delphi was bleeding edge, or trying to use their skills in the mobile space.  That ride won’t last forever.

Perhaps I have digressed a little, but my point is that EMBT has shown it’s colours.  They don’t care about code quality or their actions would speak more to it. Instead they want to add just one more feature into the box.   Perhaps a subscription model would help a little, but it won’t result in more bugs fixes.  We have been voting with our wallets for some time now, in QC, and on the forums and they are still not getting the message!  As a customer I would have to be insane not to recognize their pattern, and refuse to pay for bug fixes (it’s a great money making machine if you can convince users to do so), and choose another toolset from a company that does care.  If they did we would have seen bug bounties a long time ago…

At work we’re developing C# .NET replacements for our Delphi apps as we speak!  Good luck to EMBT.  XE4 with the infamous  ‘Out of Memory issues’ will be the last release we buy…