Wednesday, April 29, 2009

How do you improve Quality?

There typically are 3 types of projects, when it comes to quality that I have seen.
  1. The focus is getting the code out the door and then you pick up the pieces.
  2. The focus is on getting quality code out the door until deadline nears then you revert to number 1.
  3. The focus is on getting quality code out the door and as deadline nears features may be dropped and the deadline may slip.
When the project starts everyone seems to be on board with the idea of #3 but typically I have seen it slip all the way to #1 quite quickly.

At my current employer we have an internal application that is used by 300+ end users.

We used to have:
  • ZERO people dedicated to QA. (4-5 Delphi Developers, 1 Mainframe Programmer, no analysts)
  • Testing was done by end users testing as they had time.
  • We had no automated or unit tests.
  • The build process was compile from your own machine and copy it the network, with any developer free to release any code they wanted. Which would sometimes step over the other developers uncommitted code.
  • We had two environment's
    • Development used by both developers and testing.
    • Production
  • Exceptions had no details or context to help track down problems.
  • We had a very small and painful bug tracking system.
  • We would commonly be related to #1 type model above.
Over the few years that I have been here we have made many changes.
We now have:
  • We now have three people dedicated to QA. ( 7 Delphi Developers, 1 Database PL/SQL developer, and 1 Analyst)
  • We have end users still testing with the time that they have. But we now have better management support to get additional time needed.
  • We have a few automated tests, and a few more unit tests, but we really could use many more.
  • Our build process runs every hour through Final Builder, alerting us with email when someone checks in bad code.
  • We now have 4 environment's
    • Development (Dedicated to Developers only)
    • TEST where users get first look
    • QA a final look before production usually with data refreshed from production
    • Production.
  • We now use the JCL Debug to help use find those Hard to Reproduce Errors.
  • We have a better bug tracking system, but still not nearly as nice as some of the home grown solutions I have used at past employers.
  • We are now some where between the #2 and #3 model's above.

Every release we ask what can we do better? We try to learn from our mistakes and implement solutions to prevent problems. We release a new version of our software nearly every month, so we are continually improving, and quality has improved in many ways in the past few years.

However, today I feel awful!

We put out a release on Friday morning last week. I don't think I have ever had a release go bad as this one has. Today we are still working on fixing major problems that were caused by the release.
  • Some of which would have been caught by better testing.
  • Some of which would have been caught by better management of the information coming in about problems. (i.e. it was reported but not acted on!) Since, I usually manage this information, it's the reason I feel awful.
  • Of course like all systems some of them would have taken an unreasonable amount of testing to find.

So I have been thinking, it's time to go back to and look at quality in new and different ways.

I have been making a list for a while that specific to our product on ways to improve quality. Several items on the list are general enough to share with others.

  • Build a health check system detects common/possible problems that can be run daily in each environment's, which is very database specific. We have scripts for all of these, but not an automated way to run them.
    • Tables without primary keys
    • Missing Synonyms
    • Invalid Synonyms
    • Tables without indexes
    • Missing Grants
    • Disabled Constraints in Oracle
    • Tables that have not been analyzed recently.
    • FK Constraints without index on child table (table level lock will be placed on the parent table if these are found)
    • Invalid Database Objects
    • Plus several that are specific to our schema, i.e. constraints that can't be described in meta data.
  • Error Messages (Exceptions)
    • Ability to Send error messages to a web service
    • Ability to capture a screen shot with the error message.
    • Ability to ask users what they are doing when the exception occurred.
    • Ability to attach reported errors to items in bug tracking system.
  • Code Review to help identify and build additional unit tests around the code.
  • Automated Performance Testing Benchmark system. (I think DUnit has something that will work for us)
  • Get current Delphi Unit tests into an daily build and smoke test instead of just being run by hand by developers.


I have shared some of my ideas on how to improve quality, as well as some of the things we have done.

How have you improved Quality in the software you write?

I am open to any suggestions, this is just a small attempt to think out side of the box.

Since I just started this blog, I really hope that someone is reading this and has some good ideas they are willing to share.


  1. Hi Robert,
    Thx for the very interesting thoughts on Code/Product Quality.
    I fear, "good" principles hardly apply everywhere at any time. Though, sharing good ideas allows one to improve himself... Hence my 2c :)

    Under a multi-developers coding configuration:
    - review / update / improve corporate coding guidelines regularly.
    - avoid branching of code if it's not absolutely necessary.
    - comment "bugfixes" in the code twice: once in the unit header and once on place of the modifications. Form of comment should follow guidelines.
    - VCS check-in should always be labeled with bug (or enhancement) ID and short description.
    - review the specification twice before coding and always request detailed information if something is not 100% clear: wait for clearance! (Hmm... it's an obvious one ;).
    - PROHIBIT development of any new function 2 weeks at least before release deadline => avoid slipping deadline.
    - FREEZE bug fixing development, but for Prio 1 bugs.
    - Update your tools - hence update your knowhow about dev technology - reading blogs regularly helps out :)
    - Build the skills of the programmers up !

    this list isn't exhaustive, though.

    One important point I'd like to highlight is:
    Review / analyze the past development periods !

    Using a ticket system (Tic@re, Bugzilla...) allows to statistically evaluate the way your code is produced.
    - how long does it take to fix how much bugs of prio 1, 2, 3?
    - which modules of the software are bug sensitive (business critical)?
    - which modules are razing most of the bugs?
    - how much bugs will be reported in the final phase before release?
    - ...and so on ...

    e.g.: this kind of analysis could lead to the conclusion that one of the main module should be refactored from the scratch.


    p.s. :
    I used to work for an indian ISV 2 years long.
    The up to 20 developer teams there have a "twice-a-day 15 minutes long all together meeting in the corridor" session.
    And it was great !
    Information flow is really important!
    - point out "who needs help?".
    - sustain allegiance and kinship through "What are you doing in your cubicle all the day long?"
    - more efficient suggestion sharing.
    - communicate weak points and strengths.

  2. Use MadExcept ( instead of JclDebug. You get automatically Screenshots on Exceptions and Uploading the complete report (or Sending per eMail) it to you.