Software Quality

October 22, 2011

Software Quality – What should you know today? What should you learn for the future?

Filed under: Code Contracts, Practices, Testing — David Allen @ 8:11 pm

How can we make good software? What are current best practices and what are some promising areas for future development? In this post, I share a couple of ideas that you can use now, and a few ideas to keep an eye on for the future.

Our current practices should include

  • automated unit testing
  • design by contract
  • Test-Driven Development (TDD)

Emerging ideas to watch include

  • automated test case generation
  • model-based verification (more…)

November 17, 2010

Tips for achieving quality in software

Filed under: Code Contracts, Practices, Testing — David Allen @ 7:53 pm

Here is my short list of techniques for achieving quality in software:

  • Code-driven Testing
  • Programming by Contract
  • Heavy User Involvement
  • Code Reviews
  • Test Automation Reviews

 Do you have any suggestions or disagreements? I would welcome other ideas. I might not put all of the suggestions on a “short” list, but I am eager to hear what others are doing these days. Please post your ideas.

 In my job, we do the first three practices (most of the time), but do not do code or test reviews very often. However, we certainly do ask for help from one another, which might count in some cases as a “code review.” Below, I’ve provided more details on what I mean by these terms.

Category Practice Description Qualities Enhanced by Practice
Coding Automated Testing

Favor Code-driven testing where possible

Write automated tests for all features, and run the tests often. Write them first where possible (also known as Test Driven Design). What do you gain? Automated tests detect coding defects quickly, so they can be fixed before the software is seen by anyone other than the developer. If you write the tests first, you also gain additional clarity in requirements and uncover more requirement defects sooner. And writing tests first helps you ensure you do not “forget” to write tests later.
  • Reliability
  • Fitness for Purpose
Coding Programming by Contract Embed automated assertions in your code to express rules (contracts). Eiffel has this built in to the language (thank you Bertrand Meyer). Microsoft .Net languages have this available in the 4.0 version of the .Net framework (thank you Microsoft).
  • Reliability
  • Maintainability (by virtue of clarity from expressing rules in code)
  • Diagnosability (by virtue of detecting failures sooner than you would without contracts)
Collaboration Heavy User Involvement Involve real users heavily, throughout the process. This may seem obvious, but I challenge you to explain whether you are really doing this on your current project. What do you gain from this? You detect requirement defects quickly, and produce more usable designs.
  • Reliability
  • Usability
  • Economy (by reducing wasteful rework)
Collaboration  Code Reviews These come in many styles. Old style code reviews involve a partner or several, reviewing code line by line. Modern alternatives include pair programming which includes code reviews and much more.
  • Maintainability
  • Fitness for Purpose
Collaboration Test Automation Reviews These are like code reviews, but you involve multiple people in developing or reviewing test plans. My favorite approach is to do Test Driven Design with input from my team’s professional tester.  Usually, the tester first writes some test cases in collaboration with the business analyst and maybe the programmer. Then I translate those test cases into automated functional tests.   This raises the quality and value of my tests a great deal.  To enhance the technical aspect of the test automation, I may ask for help from another programmer. In pair programming, you automatically get this.  If you prefer a more sequential and less collaborative process, there is a detailed article on how to do these on MSDN. Although that article describes a process that is too formal and sequential for my test, it has some good ideas and makes the point powerfully. So I encourage you to read the introduction for principles, and proceed to pursue the implementation in whatever manner suits your culture. 
  • Reliability
  • Fitness for Purpose

Tip to achieve quality when outsourcing development:

If you are a developer, you can introduce these practices or adopt them yourself.  If you delegate development work to remote development groups, you can use automated tests as a part of your specification. If they get the test to pass, then the code is considered acceptable. This is a smart division of labor. You can have a small, well-informed development team write automated tests, while a larger outsourced development group could write the implementation. Programming by contract is another powerful tool to improve quality in the outsourcing scenario, because it helps to prevent accidental misuse of existing code.

May 18, 2010

Code Contracts really speed development

Filed under: Code Contracts, Uncategorized — David Allen @ 8:45 pm

I was out of the office for 2 weeks. When I returned, I was pairing with two of my coworkers. They each reported cases in which code contracts alerted them to accidental misuse of code. They probably would have found their problem eventually. But the presence of code contracts, combined with a rich set of automated tests, detected the problems sooner than they might have otherwise.  This was more positive reinforcement for me that code contracts are a valuable technique to include in a system’s design. They help steer you or your coworkers away from incorrect usage.

Don’t forget to add the optional descriptive text parameter to your contracts. What is a “good” contract comment? Imagine you are another programmer, and you accidentally violate a contract. Is the reason for the contract’s existence obvious to you? If not, then you should explain WHY the contract has been placed there.


void Deposit(decimal amount){
   Contract.Requires(amount  > 0,"system does not accept zero or negative deposits");

Code contracts are just one technique for your toolbox. But they are a useful tool to include in your systems. So don’t forget to develop your skill at contract programming.

April 8, 2010

Presentation on code contracts to Twin Cities Languages User Group Thursday, April 8, 2010

Filed under: Code Contracts, Presentations — David Allen @ 8:06 pm

Tonight I gave a talk on Microsoft Code Contracts to the  Twin Cities Languages User Group.  I appreciate all the people who took time to attend.  I enjoyed the dialogue.  Participants had some great questions and comments. The slides amd demo software in Visual Studio 2010 RC format, are available at my download site.  Here were just  a few questions and comments made: (more…)

March 20, 2010

Code Contracts March 2010 Release improves code coverage

Filed under: Code Contracts — David Allen @ 1:26 pm

In previous releases, if you used code contracts and code coverage, your code coverage might be understated due to distortions in the analysis of the code inserted by the code contracts rewriter.

I tested the new version and it fixes this. So now, code coverage behaves as I expect. If you see partial coverage in some contracts, remember to write automated tests to exercise those alternate paths that cause contract failure.

Get the release at

February 20, 2010

Presentation on code contracts to Minnesota Visual Studio user group Wednesday, February 17, 2010

Filed under: Code Contracts, Presentations — David Allen @ 2:00 pm

On Wednesday, February 17, 2010, I gave a 90 minute presentation to the Minnesota Visual Studio User Group, on the use of Microsoft Code Contracts to improve software quality. Approximately 17 programmers attended.  I used several Visual Studio solutions and several PowerPoint presentations. All of the materials can be downloaded from my download section. In addition, I have summarized several of the questions that were asked by the participants. For each question, I have included the answer that I gave them, as well as additional thoughts I had after further reflection.   If any of you are giving presentations on the topic of code contracts, feel free to use any of the slides or sample code. 


You have demonstrated how to use a precondition. But I don’t see why I shouldn’t simply use my traditional “if(x) then (do y)” statement to validate arguments. 

Answer I gave:   (more…)

Older Posts »

Blog at