12 Practical Tips for Building Bug-Free Software

If you are a .NET, Java or Delphi developer, please take a look at our advanced logging tool SmartInspect.

Does your software application have bugs? Of course it has, every software application that’s out there has bugs and bug-free software is a myth. But it’s still possible to greatly minimize bugs, security problems and errors in your application by following a few tips and techniques I outline in this posting.

Recent studies show that up to 40% of system failures are caused by software bugs and that common memory and concurrency related bugs account for 60% of system vulnerabilities and security problems. So reducing software bugs in your application is the best way to increase the stability, reliability and security of your software.

During the development of our logging tool SmartInspect, we used many techniques to keep the quality of our product high and this list contains some of the techniques we use. So without further ado, here is my list of 12 practical tips for building bug-free software (or at least software with fewer bugs):

1. Code Reviews

Four eyes see more than two. That’s why you should let other developers review your source code on a regular basis. Pair programming on the other hand, a technique where two developers write code together for longer periods, isn’t for everyone and is often not needed. But complicated, important or security related code greatly benefits from code reviews and will improve your code quality a lot.

2. Beta Tests

Beta tests play an important role with keeping your software’s quality high. But most times, it doesn’t make sense to release beta versions of your software for minor updates. Major releases on the other hand, should be tested by end-users and customers before going gold. You can test your software as much as you want, if you cannot control the execution environment, the chance is high that end-users will find bugs and problems with all the different computer configurations out there. Also make sure that your software reached a high quality standard before giving it to beta testers. You don’t want to waste the testers’ time by letting them find and report bugs that you already know about.

3. Automated Tests

Automated tests like unit tests or automated GUI tests can be used to guarantee the functionality of application modules, application programming interfaces (APIs) and user interfaces. You don’t have to be a test-driven development wizard to make good use of automated tests. Using unit tests for key parts of your application can go a long way towards building more reliable software. There are tons of unit testing frameworks, web and GUI testing tools out there that you can utilize.

4. Logging

Using log files or live logging during development and production usage is an important and useful technique to identify bugs, find concurrency problems and to analyze and find out why an application crashed. Advanced logging tools are also able to log complete objects, trace threads and distributed systems and offer rich viewer tools to monitor your application. Instead of writing your own basic logging framework, you should use proven and advanced libraries and tools. Many open-source and even some commercial offerings have been released over the years, including our own .NET, Java and Delphi logging tool SmartInspect.

5. Error Reporting

To find and resolve errors and exceptions, you first have to know what kind of errors your users and customers are experiencing. Many users of trial software won’t get in touch with you to report any errors. Instead, they will just uninstall your application and test a competing product. To make error reporting for end-users easier and more useful to you, you should use automated error and exception reporting techniques. When an unhandled exception occurs, your application should show a friendly dialog offering the user to send an error report back to the developer. Error reports should contain all kind of information to help you identify the problem, including error messages, call stacks, version numbers and log files.

6. Customer Feedback

Similar to error reporting, you should make giving feedback as easy as possible for your users and customers. In SmartInspect, for example, we have buttons in the menu and toolbars to send feedback and questions. You can also use a short (optional) survey when a user uninstalls your application. This survey should only have a few questions and besides other things ask why the user uninstalled your software. If a lot of users report that they uninstalled your software because of stability problems, you will know that your application isn’t as high-quality as you have thought.

7. Use Proven Code

You should build the core functionality and main features of your applications yourself, because only then are you able to easily and quickly modify and improve it. But for many other parts you can reuse existing and proven code. It will take you years to build a stable, easy-to-use and feature complete reporting engine or setup builder, for example. Often times it’s better to use proven existing code, either from internal libraries, third-party companies or open source solutions if the license permits this.

8. Dedicated Testers

If possible, you should have dedicated testers in your organization for quality assurance. In fact, you should have lots of them. For simple standard applications, one tester per developer is a good rule of thumb. For applications that are complicated and time-consuming to test, two or more testers per developer are needed. Many small organizations cannot afford dedicated testers. If this is the case, developers should test each others’ code. It’s important that others test your code and functionality, because general wisdom says that developers do a really bad job testing software that they wrote themselves.

9. Virtual Machines

To test your software on as many different environments and operating systems as possible, you should use virtual machines with tools like VMware, Virtual PC or other available virtualization software. Besides allowing you to test your software on all kinds of configurations, you will save tons of time because you can easily copy, share and reset the virtual machines. It’s a good idea to create many different standard images for all the operating systems you regular test on and put them on a file server. When you need a specific configuration to test something, you can then start with one of your base images without installing the operating system, drivers and required software and so on.

10. Write a Specification

Many bugs are caused by badly designed class hierarchies, inaccurate interfaces, wrongly understood requirements and the therefore required workarounds. That’s why an experienced developer or architect should write a specification with all the collected requirements and technical implementation details before writing the first line of code. But as always, requirements change during the lifetime of a software application. That’s why it’s important to keep the specification up-to-date and plan the architecture changes for any new or altered requirements.

11. Use a Good Debugger

If you use an IDE like Visual Studio, Eclipse or Delphi, you already have access to a powerful debugger that you should use. But with many development environments and development platforms like PHP, Windows Scripting, Python and Ruby, many developers aren’t using a debugger. In those scripting environments, developers often try to squish bugs by try and error, changing code parts, adding a few print statements and so on. This is not only a very cumbersome and time-consuming way of identifying and solving bugs, it’s also very dangerous if you don’t fully understand your code and are able to step through it with a debugger. Do yourself a favor and get a good debugger for your development platform (and there are debuggers for almost everything).

12. Debug and Strict Options

Many development environments allow you to enable special debugging options like range checking, overflow checking and memory corruption checking. Such options should be enabled during development and sometimes even during quality assurance to identify hard to find bugs. Many script languages like Perl or PHP on the other hand allow you to enable certain rules and warnings that will force you to declare variables before using them. This is especially useful if a script language is case-sensitive and it’s easy to make typos.

As I already said, these tips won’t make your software magically bug-free, but they allow you to make your software much more stable, reliable and usable if you put the work into it. And on top of it, it will make you a better developer, too.

This entry was posted in Delphi, Development, VMware. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

5 Comments

  1. C Johnson
    Posted June 24, 2007 at 11:16 pm | Permalink

    People like to think that bugs are limited to software, but truely, it extends to other things as well.

    Ever hit your thumb with a hammer? I’d call that a glitch derived from a design flaw. Gun misfire? Car need continual maintenance and even service packs (factory recalls to install safety equipment), even upgrades and options. Consider public transit the open source version (which provides a great parallel to other open source projects on many levels).

    So yes, bug free is a myth started by those who assume that the devices around them work flawlessly when it just isn’t true. Speaking of which, I have to go debug my lawn, it keeps overflowing…

  2. Posted June 25, 2007 at 2:07 am | Permalink

    +1000 for user reporting and feedback.

    After adding user feedback and error reporting to my application, I found some bugs I myself would never have found.

    Should have added this from the beginning…

  3. R Cruz
    Posted June 25, 2007 at 8:31 pm | Permalink

    Just I will add a point, select your development tools properly. As many bugs will come from your development platform. Incorrect or bug in the compiler, that are not addressed by the manufacturer.

    We discovered that a bug free code can be a night mare on a totally crapy developer platform, when the right platform is used no bugs.

  4. John
    Posted July 20, 2007 at 7:07 am | Permalink

    Maybe R. Cruz can enlighten us about what he sees as the best Development Tools?

  5. Posted November 21, 2007 at 4:34 pm | Permalink

    Even after software deployment I recommend sending detailed error reports in case of errors/bugs. There are different tools that enable you to do this. (eg Eurekalog..)

Post a Comment

Your email is never published nor shared.