reducing the cost of change

Since my last post I have decided to re-order my tenets of good coding.

The new number one is:
REDUCE THE COST OF CHANGE

All others are still very important, but this ideal is important for several reasons:
- it gives you a guiding principle to work towards
- it allows you to work faster
- it makes the politics behind business easier
- it requires most coding best practices to work

So, because of all of these points I think it's a great way to direct developers to write better code.

Let me elaborate on my points listed above:

It gives you a guiding principle to work towards
If you keep this principle in mind, the decisions required to implement functionality become clear. An example: Suppose that you need to add just one more step to a function. The easy way is to just add the code to the current function. Hmm? No, that doesn't seem right. Surely a separate function that executes the new logic that is called from the other function is a better idea. Why? Well because you have abstracted the execution of the function and if named appropriately then there's even no need for comments. As a bonus you get reuseability and testability.

It allows you to work faster
OK, another example: I was working on something that had to save data from a new application that allowed more data (30 chars) then the old (15 chars). I assumed that the business would want me to save whatever would fit in the 15 chars from the 30. So I worth a small function that did just that and called it from all appropriate places. I had also asked the business to determine exactly what had to be done. They decided that I should only save the data where it was 15 characters or less. No big issue - I just changed the one function and it all worked. As the cost of change was quite low, I was able to assume what was necessary and continue, whilst waiting for the business to decide. If I had got it right, then great, if not, then it's easy to change.

It makes the politics behind business easier
This happens to all of us - the management want the application done now and you know that to do it that quickly will compromise design. So what do you do? Implement the functionality, ensuring that you have reduced the cost of change as much as possible - that way if you need to work with the code later, it will be easy to extend.

It requires most coding best practices to work
How do you reduce the cost of change? Well, the simplest answer to that is to write small discrete functions/classes that are single purpose. Use abstraction and encapsulation to reduce coupling and allow re-use. This will also mean that your code will be more (unit) testable. I could write oodles of stuff on best practices - but there are lots of great sites/blogs out there already.


Oh - happy new year!