I’m Touched

Normally, when you fix a bug in a particular section of code, you also look at other bug and enhancement reports related to that area to see if you can also fix those issues, or implement those enhancements.  Otherwise you’re judging one report in that area against the other in terms of frequency and severity to determine which ones get addressed.

That’s why it came as quite a shock that in XE3 QC items 104640 (B3 opened 4/6/2012), and 107227 (B2 opened 7/19/2012) were addressed in amongst numerous others in the IDE, IDE\Code Editor category, but other QC  items relating to Code Completion were not, including my own QC99381 (B1 opened 7/27/2011).  It’s shocking because, I run into this code completion bug on a daily basis where the issues that got fixed appear to be edge cases.  In fact 104640 has a lower severity than my report, and was opened long after mine.  I don’t know what prioritization algorithm EMBT uses, but I find it baffling!  So that’s one major release of Delphi later, with several updates, and 4 hot fixes.

Addressing all issues in a specific area all at once, in my experience, works best.  That’s because the developers get their head into the problems, and code.  This takes a while, and it’s been proven that having developers juggle multiple things either concurrently or in quick serial succession, makes them less productive.  It’s simply the power of focus.  It also makes testing an area thoroughly easier, especially if it requires manual testing, requiring less time from Q&A.

Apparently breaking functionality in one release doesn’t necessitate fixing it, even in a following release that developers have to pay for.  How do you feel about that practice?  If a bug is introduced in a release should it be fixed and provided in that release for free?  Where would you draw the line knowing software is never perfect?

If Marco Cantu is indeed the special guest at CodeRage 7, and the announcement is indeed that he is the new Delphi Product Manager, I hope he is empowered to change the way QC items are handled.  As a developer who actually uses the tool, perhaps he will also address the poor template support, re-factoring, code navigation, and remove the half baked useless “features” like the Object Inspector Description pane (I currently use his package to hide it), and complete others like Error Insight that could be more useful with less false positives.  Let me be the first to wish him well in that role if the commentor Inside Embarcadero is right.

Tags: , ,

4 Responses to “I’m Touched”

  1. Warren Says:

    Code completion bugs are quite frankly nearly un-fix-able in the current codebase. I know these things. I’ve talked to the devs who know that area of the code, and it’s clear that they would have fixed a LOT of things about code completion if they could, but they simply can’t. Not without a rewrite. Product management seldom gives the devs the freedom to do this. It’s not a question of prioritizing a few QC issues. It’s about giving an architect the freedom and the time to rebuild the next generation Delphi compiler and build an IDE built around a SINGLE parser/lexer with a single grammar, instead of several parsers, each of which support a slightly different subset of the overall delphi grammars in real use in delphi code today.


  2. Chris Says:

    “Addressing all issues in a specific area all at once, in my experience, works best.”

    Although, Delphi’s a big product - looking to address ‘all’ issues in a ’specific area’ wil run the risk you pick an area that most customers, in practice, aren’t really concerned about. E.g., you think Error Insight is worth persisting with. Maybe that’s the majority view, but my own is that I wish it were just removed. Conversely, I think the FMX core needs some proper love, whereas you might think EMBT should just cut its losses on the ape - and if you don’t, plenty of other Delphi developers do.

  3. Larry Hengen Says:


    Good point. I have certainly been in that position myself - where a re-write was required but I was only authorized to band aide it.


    The area picked should reflect QC with it’s voting, and issue prioritization attributes. That should eliminate most of the risk of picking an area that customers don’t care about. If it was important enough to put in the product in the first place, then it needs to be maintained properly.

    I agree that there is a lot of dead-weight in the product now. How many developers use the documentation generation, and modelling? I’m all for ripping out what Borland packed into the box during their Inprise days, but how does EMBT know what is actually used? Are there usage metrics collected? If not, why not?

  4. William Meyer Says:

    Warren, I would have to accept your assessment. Certain of the behaviors have been stable and wrong for a long time. I’m sure no one at EMB likes having those problems remain, but as tools evolve, it does sometimes happen that the only reasonable solution is to redesign and rewrite.

Leave a Reply