I know this sounds like a funny thing to say - only make your code worse when you mean to. But think about the alternative - make your code worse without meaning to!

To explain this, I must mention a concept I heard from Ward Cunningham - code debt. Code debt occurs when you go in and hack something into your system. The next time you come into the system, you have to spend a couple of minutes figuring out why you did it this way, or maybe you know you were hacking, but it still takes a little longer because it isn't clear what you did. Hence, you've increased the debt of your code. Everytime you want to make an improvement, you have to pay a little "interest" before you can get to the improvement. Enough debt and your software is bankrupt - you have to re-write the system.

Now, does this mean that you never put debt into the system? No. There are times you in fact, have to hack something in. However, you should be consciously aware that you are not writing quality code - you should be making a conscious decision that refactoring is required yet isn't taking place. There are (few) good reasons for this. A conference coming up, and I am sure something else.

However, the point is, you should not be writing code without paying attention to whether you are adding debt to your system. If you have to increase the debt, do so knowing there is a compelling reason, or the debt isn't worth worrying about (although it almost always is).

Technorati Tags: Testing Lean Lean-Agile

tag with del.icio.us