Design Notes: Reducing Opportunities for Error

• Download demo - 4.8 KB
• Download source - 11.9 KB

Introduction

Consider the example dialog box shown here. What is the real difference between the two approaches when it comes to software quality? Example 1 is easier to produce, whereas Example 2 took more effort and some research by the developer to produce. This article examines why a developer should spend the extra effort to reduce the opportunities for error by the user.

Defining Opportunities

A good analogy for applying this concept is to think of the software product as a factory that takes orders from the user and produces a product of data. Therefore, the emphasis for this design method is to take better orders and produce a higher quality product. The first part of this process is to define measurable objects to be able to calculate opportunities. Some good metrics to start with are the number of database fields and the number of user interface elements (textboxes, buttons, menu choices etc).

Once a count of the objects has been established, the next step is to calculate the number of occurrences. The next set of metrics will be harder to come by, and may need to be estimated, but they are important to providing a proper analysis of where to reduce opportunities. They are metrics like the number of database records and number of users. Now, the number of opportunities for error is: the number of objects x the number of occurrences = opportunities for error.

For example: a database with 15 fields and an estimated 10000 records will create a potential 150000 opportunities for error. Automation added to a software product that reduces the number of database fields by 2 reduces the number of opportunities by 20000, and it typically does not take 20000 lines of code to add that automation.

While it is true that an opportunity for error does not equate to an actual error, it is reasonable to assume that a percentage of the opportunities will become actual errors. If you reduce the opportunities then by inference, you will reduce the actual number of errors, thus creating a higher quality product.

Example 2 reduces the number of objects on the user interface by one, and effectively reduces the opportunities for error by checking the user entered date and not requiring a user entry to determine the Membership level. I have attached the code for this optimization for your reference. In this example, it only took 9 lines of code to make this reduction in opportunities for error.

private void dateTimePicker1_ValueChanged(object sender, System.EventArgs e)
{
     DateTime dt = DateTime.Now;
     TimeSpan ts = new TimeSpan(dt.Ticks - dateTimePicker1.Value.Ticks);

     //if duration is > than 2 years in days
     //else if duration > 1 year in days
     //else less than 1 year

     if(ts.TotalDays > 730)
     {
             label7.Text = "Gold Member";
     }
     else if (ts.TotalDays > 365)
     {
             label7.Text = "Silver Member";
     }
     else
     {
             label7.Text = "Bronze Member";
     }
}

This article is intended to demonstrate another method for analyzing the trade off between placing the work on the developer vs. giving that work to the user of the software. It also starts to outline the process for quantifying the need and justifying the additional work to be added to a project.

History

• 4/20/07: Original release.