Easy to Test, Easy to Change

In conversation with my wife recently, I mentioned that I’ve been doing software development for more than 40 years. I’ve learned, forgotten, and re-learned many things in that time.

There are two goals I now accept as true and self-evident but are neither readily nor universally implemented, especially in high-pressure product-development environments where short-term progress is traded against long-term success.

Those two goals are more important than “providing the functionality we want”. They are that code must be:

  1. easy to change
  2. easy to test

Without these, maintaining the functionality we want (as that functionality evolves) becomes far too hard.

And that functionality will and must evolve. It must change, frequently. If we are to have any hope of doing that efficiently or effectively the change needs to be easy and it needs to be safe.

Many software developers would accept these needs as true—in fact it is repeated as common lore in all the places you might look—but few have the opportunity to implement it.

What can we change? How do we make these goals the most important?