CodeGear Quality Review 2007

Since we’ve just released the December 2007 update for RAD Studio 2007, Delphi 2007 and C++Builder 2007, this seems like an appropriate time to reflect on this years work. (see http://dn.codegear.com/article/37350 for details on the update). 

First a few statistics: Since January 1, 2007 a total of 7006 defects have been verified by QA as ‘Fixed’ or ‘Retest’ between Delphi, Delphi.NET and C++Builder. This excludes duplicate reports, test case errors, or ’as designed’ reports. That’s a whole lot of product loving, in my opinion. 1196 of these reports are from Quality Central, which personally I’m glad to see the community feedback being used to help prioritize bug fixing efforts. 

The team also released three major products, each having as much testing and fix time as main development - Delphi 2007, C++ Builder 2007 and RAD Studio 2007.  Each release provided additional fixes to the previous, though it certainly made for a complex install environment.So there is where we are planning to focus next. Install needs work, and though that may not directly help current customers, we want a reliable, efficient and simple installer to get our products up and running on your systems in as efficient a manner as possible. Stay tuned for more information, since I expect to put a call out for field testers in Q1 2008 for helping ‘beat up’ new version(s) of the installer to see how much we can improve it in terms of performance and reliability.

2008 will be an interesting year - Unicode is on the roadmap, and work has already started. We’ll also be looking for users with complex projects to join the field test to exercise their projects against the next release. Odds are we’ll be simpler with the install (no multiple small releases - a pity in one way since we got tons of core fixes that way, but on the other hand made for very complex upgrades/patches!), yet nothing is finalized yet. I’d like to thank the CodeGear development team for putting a really big focus on quality this year. We put considerably more ‘bake time’ into the past few releases then in the previous years, and I strongly believe this helped both the products and the developers who use them.  And I’d really like to thank the field testers and field test marshal’s who were vocal in a very constructive manner, and effectively used quality central to report issues, and help prioritize them.

We made some improvements already to Quality Central (such as increasing maximum number of votes considerably, and allowing users to vote on hundreds of reports!) and much more on the way. We’re working to centralize our bug reporting to Quality Central instead of using RAID (kudos to RAID to serving us so well for so long) mainly to avoid the team having to look in two places for information, and two systems makes it too easy to let things slip between the cracks. Internally, I have quite a few plans, and the QA team is already working very hard on them - running automated tests on localized builds (already run against German a few months ago, now need them automated daily), a quality dashboard with test results, test coverage and performance metrics, and integrating more real world projects into our test system. Reminds me, I’d like to thank several of our long term customers for submitting their business source code demonstrating performance and stability problems, leading to significant fixes in performance and nailing some nasty memory leaks.

 Let’s do more of that in 2008, and make it even a better year. 

14 Responses to “CodeGear Quality Review 2007”

  1. Thomas Mueller Says:

    Hi Chris,

    I like the new, more open approach of CodeGear much better than the old Borland attitude. Also, I think the improvement to the QA process since Delphi 2005 shows by now.

    twm

  2. Michael Little Says:

    I agree with Thomas, the new openness of Codegear is like a breath of fresh air.

    The "we’re not perfect, but we are trying" attitude is a complete departure from Borland of old and really inspires confidence.

    I could become a Delphi fanboi again..

    Michael

  3. Arturo Martínez Says:

    I’m sorry, but I don’t agree.

    I’ve checked your whole list of resolved issues and I’m not impressed at all nor consider it a great advance.

    So, you have fixed the help system so now I can see the help for TButton from the form designer? Well, gee, thank you for that. But you know what? I still can’t build my entire source tree without checking it out first from the VCS because the IDE insists in that the files are read only (QC #51338 and #45860). I still have to click "No" 29 times when I close my main project group because the IDE asks me if I want to save changes in each project of my project group, just because the IDE hasn’t a "No to all" button (QC #50343).

    I’ve used Delphi for the last 10 years, I DON’T NEED the help for TButton, I don’t need the "refactor" menu to be properly translated to french. From the 93 Delphi 2007 fixes I can’t find anything that I really need. Yet I must to go through the hard InstallA-BUG-ware process to stay up to date and see if I can get to work without having to kill the IDE 3 times a day from the weirds AV I get sometimes on coreide100.bpl (Windows Vista Ultimate 64bits, 4GB RAM, no Together, no BDE) that I don’t even know how to reproduce.

    Few weeks ago I saw some "10 reasons to upgrade from Delphi 7 to Delphi 2007" articles, but I must say that my developer experience working everyday was way better with Delphi 7 + CodeRush. I wish I could get the same with D2007.

  4. Warren Says:

    If somebody could finally fix the three long-standing QC annoyances Arturo mentions, I’m sure everybody would sigh a breath of relief.

    Arturo, however, I do think you’re descending into whining here. Yes, install-aware is slow, but that’s because it’s MSI based. It’s MSI based because they are installing dot Net runtimes. Which decision, to embrace .NET as a core part of the technologies used to build the IDE itself, by the way was the biggest mistake every in Delphi’s long history.

    I also suffer from continuous, persistent access-violations in the IDE, and I believe that unless CodeGear provides a debug-build of the IDE that we can use to track down and localize the causes of these crashes, we’re never going to get anywhere on that all-important but hard-to-reproduce IDE crash meta-bug, which is perhaps the #1 showstopper on everybody’s list. Maybe, hopefully most users never experience these crashes. But for those of us who do, it’s little comfort that other people aren’t so unlucky as we are.

    Warren

  5. Anders E. Andersen Says:

    I vote for more doc fixes. IDE works most of the time and there are workarounds for when it doesn’t.

    But not being able to look up simple documentation because of the "this is foo of class bar" error can halt your ability to develop completely.

  6. DelphiUser Says:

    +1 to Anders E.

    I use D7’s help (also installed on my PC) or even refer back to my D5 paper docs.

    I don’t know how a noob to Delphi possibly manages to be productive in D2007. This is so in-your-face, it isn’t funny.

  7. Arturo Martínez Says:

    @Warren:
    "If somebody could finally fix the three long-standing QC annoyances Arturo mentions, I’m sure everybody would sigh a breath of relief."

    Well, I’m sure I’d sigh a big breath of relief. Everytime I need to build my source tree I need to manually remove the read-only attribute to all the files for the IDE can compile. In Delphi 7 I could build all the source tree even if all files were read-only, as they are if you are working with a VCS like Vault. VS2005 doesn’t have this problem either, and I work with a lot of C# projects with the same VCS which IDE integration is, by the way, fantastic (oh yes the grass is so green in VS2005). So yes, if you do use Delphi for more than build shareware MP3 player applications, if you use a VCS and an automated build system, then you know what I’m talking about.

    "Arturo, however, I do think you’re descending into whining here. Yes, install-aware is slow, but that’s because it’s MSI based"

    Is that so? Then why I don’t have those weird problems and ever-lasting installing processes on VS? All VS installers are MSI based, yet they all work fine. InstallAware is slow because it’s just a bad installer.

  8. Chris Pattinson Says:

    I did miss mentioning we also did a documentation update, and have another in the works. We’ve been adding and fixing lost content, and F1 linking.

    Doc quality has been one of the biggest core complaints, and we’re still working on it. You should see more improvements in the coming months.

    Arturo, sorry we didn’t nail anything you were looking for. Highly recommend you and others interested in these fixes go into QC and add your votes. There are still thousands of issues to go after and we’ll want to go after the top ones first.

    Usually that means crashes, broken functionality and regressions. However we do want to improve usability and that’s what it sounds like you are asking for.

    Regards,

    Chris

  9. Joe Hendricks Says:

    I am encouraged by the trend! And thanks Chris for your participation in the newsgroups.

  10. Bill Says:

    All went well when I ran the December Update although as advertised it did
    take 2.5 hours to install on Vista.

    The update solved the most annoying problem of the IDE not restoring from
    its minimized state when debugging (when hitting the second break point),
    but it restored another although cosmetic problem that was eliminated in
    previous updates. The "feature" of 2 icons in the taskbar is BACK!… It
    looks like a January update may be required to fix this AGAIN too.

    Did the restore from minimise when debugging bugfix recreate the second icon on the taskbar? Jeepers I hope you guys fix this too.

    Other that that so far so good with December Update.

  11. Joeri Sebrechts Says:

    Good news to hear unicode is still on the win32 roadmap. We are currently in the process of migrating our 12 year old 2 million line codebase to Delphi.NET primarily for unicode support (project started over a year ago, nearly finished now), and we’re wondering now about the value proposition of completing this migration versus waiting for D2008 and porting to that. Do you have any thoughts about the effort that will be involved in migrating to unicode on win32? By the way, we’re definitely interested in beta testing D2008, whether it is specific to unicode support or in general. You can contact me at js at mcs.be (but I will check these comments again).

  12. m. Th. Says:

    Hi, Chris!

    1. Just one word: :-) !
    2. Just two words: Merry Christmas! Perhaps I don’t have other occasion and it’s also your day name, isn’t? :-)
    3. Just three words: Tiburon field test. Yes, it will be a whole bunch of work to do
    and here perhaps that I have a small experience because we dealt with Unicode issues
    from several years, now. But perhaps a hidden (for you) problem is (to quote Chris
    Bensen) "you use Delphi in a very different way than we do". :-) You see, in our (’our’ here = community) programs the VCL’s presentation layer is almost replaced entirely by 3rd party components, as you (probably) know. So, it will be a rather sequential process in order to test our ‘real world’ projects, because we need to wait those 3rd party vendors. Fortunately (in our discussion) the market it’s pretty mature one so there are few major players in most areas having unfortunately (in our discussion) huge libraries making entire ecosystems (DevExpress, FastReport, IBObjects for ex.). So, my proposal is to start ASAP. Also, another reason is to allow us to test Tiburon without these libs, just with simple programs in which we’ll embed our algorithms/procedures related to strings in order to fix them in a ‘clean room’.

    Just my 2c & Merry Christmas again!

  13. jesu Says:

    It seems you are doing a good job with new bugs but you are forgetting old ones.

    For me it would be much more useful if you solved issues like the very buggy ordering part in Midas.

    When I do "order by 1" I want data ordered by the first field, not by the 2nd or in reverse order (I’m talking mainly about D7 here -with Midas.dll from D2006-) but I haven’t seen in Codegear articles any mention that it works right in D2007. That could be a reason to upgrade.

    And no, I can’t reproduce it because it seems to work different each time I write a new query, but you could take a look to QC 55581 because it could be related.

    By the way, the option to do
    Indexfieldnames := ‘FIELD1 ASC; FIELD2 DESC’
    is long overdue.

  14. Qian Xu Says:

    Hi Christ,

    To eliminate old issues is obviously the best answer to all honest Delphi fans.

    Please take a look at this issue. I wondered, why it can be remained in database for so many years.
    http://qc.borland.com/wc/qcmain.aspx?d=6417

    Fix such kind of issues, thanks

Leave a Reply