We all aspire to write software that doesn't burden us with massive costs for maintenance down the line, but mere words about "doing better next time" are not enough. In the world of custom software development, we have an obligation to make sure that the commitment sticks.
In this article, I'll discuss various techniques that you can employ to help make these commitments stick. When people are committed to increasing maintainability of systems, these techniques can help to provide visibility into that maintainability.
Very few organizations today allow a software change to go into production without some form of regression testing. Change-control procedures generally require at least a manual script that provides an install procedure, a way to know whether the install worked, and a scripted means to back out any change that fails.
Let's start from the minimal assumption that such basics exist. The problem at this first phase is that all the steps are manual. Manual change application and manual regression testing both provide many opportunities to introduce errors. As configurations, software, or both become more complex, performing manual procedures can lead to even more errors. For example, the software for one of my clients had an install procedure that was 300 pages longassuming only a 1% error rate per page, a procedure that long is virtually guaranteed to produce at least three errors per install.