Continuous improvment strategies for software

This page is still under evolution

Preface

Software regressions cost a lot of time and energy to fix. Changes happen; they are a part of life. But It depresses me much to see a well written piece of software suddenly stop working due to a change that nobody could foresee. What really hurts is that, often, the bug surfaces much later after the guilty change has been committed. Hence, it is a worthwhile to spend some time to try and mitigate the problem.

The approaches that I have seen fall into these three broad categories:

• Continuous policing
• Single line of development, post-commit verification
• Branched development, pre-commit verification

I will first describe each of the approaches, then list their pros and cons as I see them, and then dish out my own subjective analysis. You have been warned :^)

Continuous policing

Single line of development, post-commit verification

Branched development, pre-commit verification

Example:
http://www.jetbrains.com/teamcity/delayed_commit.html

---