What causes bugs? Change.
Just seen this post on David Findley's blog - a survey on the 10 reasons why software bugs occur. It's fun to do the survey but the main reason I'm referring to it is because it's a very succint encapsulation of the root causes of buggy software. Here's the list for quick reference:
10. Poor training. (coding, business analysis, tools, infrastructure etc…)
9. Laziness – the desire to use the easiest to implement solution.
8. Compromises made in req/design to meet delivery schedules.
7. Coding methodology failures such as bad or missing error handling.
6. Vague or incomplete requirements.
5. Misunderstanding of the requirements.
4. Poor design.
3. Misapplication of technology. (Components, products, techniques)
2. Lack of testing
1. Change: to requirements, infrastructure, tools etc., because it introduces the likelihood of all of the above to happen.
As David pointed out, each one leads to the next, all the way to #1.
But the story doesn't end there. As I pointed out in the title, Change causes bugs. What's the solution? Unfortunately the answer is not 'lock down requirements' or 'ignore new user demands'.
When you are developing an application you are providing a solution to a problem which may not be fully understood, clearly defined or unchanging. Does this mean you should ask everyone to stop doing business while you write the app? Of course not. The development team has to be able to continually adapt to changing requirements in a controlled manner, understanding the need for change, assessing the risks involved, determining the new priorities and plans and communicating these with the project team.
This is not an easy task.