Delphi Quality and what are we doing?

I’ve read enough blog comments (replying to my posts) but more or less avoided answering this question. Well, I think it’s time I commented on this and hopefully, provide a peek into what we’re doing. First, I’ll start by saying that I’m not going to talk about updates to Delphi 2005, it’s not my place and not something I can/will comment on. What I want to mention are some of the things that we’re doing right now during our current development cycle related to quality.

A comment: While Borland doesn’t have an official presence on the Borland public newsgroups we (R&D/QA) do have people who read them on a regular basis. We also read the various product reviews posted to the web (some of which I’ve pointed out here) and we try to follow closely what people are saying about the product. Internally, we get feedback from our Sales Engineers in the various regions around the world which provides a bit different view that newsgroups alone and we also get feedback from Developer Support and our Dev Rel guys (DavidI, Anders and John) from their visits to developers around the world.

If you’ve been reading my blog then you’ve probably already seen this, this, this and this where I’ve been discussing some of the inner workings of our development process and answering some great blog comment questions. In my last post I talked about Handling Bugs but I didn’t cover some of the additional things we’re doing. In our current cycle, we’ve assigned a Quality Architect who is a long time Delphi R&D engineer and whose responsibility is to focus strictly on quality issues throughout the product. In fact, this person wasn’t assigned feature work so as to focusing solely on quality. Some of the functions of this new role:

  • Keeping a “report card” on the quality of the product at each milestone and reviewing it with R&D/QA/Docs.
  • Investigating, isolating and fixing or helping the engineer responsible in the area fix high priority quality issues throughout the product.
  • Attending Bug Councils (see here) and keeping close track on the overall quality picture.
  • He’s created a Quality Team which meets weekly to discuss issues

While not a comprehensive list of responsibilities these are some of the core functions of this new role.

What else are we doing?

We’re combing through QualityCentral to ensure that we are aware of and addressing issues coming from the field. For example, Chris Hesik has blogged about several instances where he’s used automated QC reports to locate and fix various issues in Delphi 2005.

We’ve allotted a much longer bug fix/stabilization period prior to RTM as well as kept tight control of feature “creep” and cut features originally slated for the release that would likely make meeting our quality goals difficult. We’ve implemented a more formal Design Specification and Review process where we’re leveraging wiki technology to allow literally anyone on the team to review, comment and help improve design documents for many the development initiatives involved in this release.

Our management team initiated bug councils at the very beginning of the process (this is generally not the case) working to prioritize the “bug base” and ensure that the worst issues are prioritized correctly and addressed accordingly.

R&D has spent time working to isolate, reproduce and fix some long standing, very difficult to reproduce issues improving our own productivity as well as the quality of the product. In fact, I’ve recently worked on a bug that was resolved via remote desktop from Japan (now that IMO is remote).

We’re leveraging various efforts of the Delphi community itself to help uncover issues and improve performance through initiatives such as the Fastcode project.

Lastly, as you can see from Allen’s recent post, we’ve really got people thinking about quality.

These are but a few of the real and ongoing efforts inside the Delphi group these days to improve overall quality. So, I hope that helps answer the question I posed above.

1 thought on “Delphi Quality and what are we doing?

  1. Hi Steve
    Good to hear that Borland is finally taking the IDE quality problems seriously. I use Delphi 2006 on a daily basis and I can assure that I lose at least 20% of development time on fixing problems caused by the IDE corrupting my source code and projects. This includes weird things like compile runs taking a few minutes instead of the regular 5 seconds spontaneously, slow ECO UML designer (adding an attribute takes 2 minutes !), unusably slow UML modelling, memory leaks, corrupted resource files on forms, spontaneous assertions, debugger not showing the value of variables so you have to use the old messagebox approach or use temp variables, and so forth. None of them are reproducible of course. For me losing 20% means losing 20% revenue as a single developer so this is a really serious problem. Next to that I expect a lot more from a product that costs 4.000 euro (5000 dollar!).
    Personally I would settle for a D2007 release with nothing new in it, but with a fast and stable IDE, an ECO system with all blocking multi user problems fixed and no more (annoying) bugs. I would even want to pay for that.
    Keep up the good work, you guys are finally moving in the right direction now you’ve finally gotten rid of the Borland mismanagement.
    Kind regards
    Bart

Comments are closed.