Test Culture Episode 8. Moving Sh*t Around.

« If you don’t have unit tests, you are not refactoring, you are just moving shit around »

I’m so sorry. I could not find the source of this quote. But you get the meaning anyways. Or maybe not… Maybe you just think that unit tests are optional and refactoring is even more optional.

If you think so you have a debt. Your project may have it’s AAA note downgraded too.

The Technical Debt

Technical debt is worst than monetary debt.
Because we underestimate it. Sometimes we even don’t know about it.
And managers are usally into money, not technic.
When you accumulate a certain amount of not-well-written code, quick fixes, broken or no tests, you are contracting a debt.
You think you saved time. But instead you borrowed it.
You must reimburse. Like companies  who survive a crisis you need cash flow. In your software you need quality flow. Always allocate some budget to maintain your code.
If you have a debt : then pay it fast and regularly.

The Unit Tests Saving Account

By introducing a culture of unit tests first, you’r building a serious provision for bad periods.

Like with a saving account you must start early. Take some time at the beginning of your project to encourage your team to write unit tests. You won’t have time when it’s too late.

When change will arrive (as in a financial crisis), you’ll be happy to have those tests. They’ll tell you if your software is still stable. This is not the only way, but it’s one of the account you should open soon.

 

Refactor To Survive

Your code must evolve. That’s the reality.

If a developer in your team has taken some time to refactor what he found was deprecated or badly-written, congratulate him.

Never blame a dev doing refactoring. That’s actually better.

Always blame a dev doing refactoring without unit tests !

That’s the key point : refactoring is often perceived by managers as lost time. It is not. It’s normal and part of any good developer job. It’s not a geeky practice. The goal of refactoring is to ensure the software gets better and ages well.

 

TODO

  • How many libraries you use are deprecated ? Do you update often ? For how long your old code has not been reviewed ?
  • Make some time provision in your budget to reimburse your technical debt.

For the developers out there

Are you participating in the debt of your project ? Do you take time to refactor of do you just add another “if” to this already-messy-method ? When you refactor do you rely on unit tests ?

Author: Jean-Baptiste Rieu

Ingénieur logiciel, passé du litteraire au scientifique. Toujours curieux, passionné d'IHM, de visualisation et d'experience utilisateur. Chercheur en méthodes pour développer la créativité. Amoureux de la Corée, pays de mon épouse. Diplômé de l'Institut de Formation d'Ingénieur de Paris-Sud XI (IFIPS).