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.
Here is 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 .NET, Java and Delphi logging tool.
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. 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.
