Fact:   90% of software dollars, and software time is spent on maintenance.  The time and money is spent on updating existing code, fixing it, or adding new features to it.

In software development we have seen a simple problem cost $250,000 and ¼ year in a hard-to-maintain software environment. The exact same problem costs  $250, and ¼ hour to fix in an easy-to-maintain software environment. In today’s rapidly changing and highly demanding marketplace you cannot afford hard-to-maintain software if you want to keep up with the market.

Most companies can make one successful change very quickly, but in almost all cases, adding one simple change makes every future change more difficult. Every additional change to the code creates an incremental increase in both cost of change and time to production.  Eventually, the software creation and maintenance process becomes too cumbersome and expensive. If you have older software it becomes nearly impossible to make fast changes and a once-easy change can take many months and many hundreds of thousands of dollars. Countless hours are spent on trying to change code. The only solution to this seemingly inevitable decline is learning how to make changes faster and more cost effective by reducing the speed of change.

How can you do that? First you need a starting point for measuring future progress. Begin by getting a an idea of the average speed of change in your organization. Get a clock and a calendar and measure, on average, how much time elapses between deciding to move forward with a small change, and deploying that change to production.

Formally define a small change. Use something such as a minimal change that impacts data, processing, and display.  Perhaps something as small as adding a field to the database and to a screen.  So long as  you have average small change defined relatively clearly, you can measure the time from decision to production. Early in your measurement process, it may be useful to break the analysis down into two parts. First, how much time passes between from analysis of the problem to pre-production?  Second, once the project gets to pre-production how long does it take to deploy to production?

You are looking for the number of minutes it takes to get from from start of work to production. And we want the answer in minutes to be a more understandable number than the answer in weeks or months.

Your average speed of change is key because there is a difference between how fast you can make one change and whether you can handle the daily changes that each team makes.

You may be asking yourself why we are talking about speed of change rather than cost of change.  In reality, they’re very similar measures.  The organization that takes six months to get a change from pre-planning to production will have a cost of change far higher than the organization with a six day or six hour cycle.

In a large organization analysis and design is often a three month process, coding adds an additional  month of work and testing is compressed into two weeks.  If you then add a six week deployment process it becomes clear why it can take six months for a small change to move from concept to production.  That is not fast enough to keep up in modern fast paced highly competitive world of software development.

A modern standard is that a small change can be tested and deployed to production inside ½ hour.  A new small feature can be taken from well-defined to ready to deploy in a day.   A customer request should move from the customer to the development team in a business week. How can you and your organization accomplish that?

Is there are recipe for making changes to your software quickly and with reliable change efficiency?  Can you construct a low average speed for your software changes?  How do you make sure that the small fast changes you build don’t break other features in your software?

The only way to meet the demand of the market with speed and efficiency is by building with Extreme Maintainability.