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.