Lately I’m talking a lot about refactoring.
Refactoring is like cleaning a kitchen.
If you observe the kitchen of a restaurant, you will see that they are cleaning the kitchen all the time.
So cooking and cleaning at the same time. (In other words I see refactoring as part of doing development)
Nobody would accept a cook to enter the restaurant and say: today the steak is 20 euro’s more expensive as we have to clean the kitchen first.
(And I presume that is when most people talk about refactoring and want a lot of money/time for it. They talk about doing a big refactoring that is more a rebuilding the kitchen instead of cleaning.)
Neither would a cook accept that I go into his kitchen and say: I want my steak half the price, can’t you not clean the kitchen today?
In the software world we let people tell us, do it quick and dirty, you can clean up after, when we have the time.
They presume it goes faster to build dirty code. Does it go quicker to cook in a dirty restaurant?
The big question is of course what to do when the kitchen is in a big mess?
(or what do you do when the code is in a mess)
There I say – use the boyscout rule: leave the place nicer than what you found.
In other words, do a little bit of refactoring to clean the code up every time you add something.
As we don’t want things to break, for me this would be start by adding unit tests.
To do this, I don’t think a team needs the approval of a manager.
A good book that helps people to learn about these first steps is Working effectively with legacy code. I recently started yet another book Reading club at a client with this book.
I’ll write more about this in a future post.
Update: Another good book is Refactoring to patterns
Second Update: Joshua created a google group around metaphors, I hope you join the discussions around metaphors.
Third Update: Joshua is also the inventor of the Limited Red Society