Reflections on Clean Code: Estimates

Day one of your iteration, your team is doing the planning game (planning poker, ideal hours, etc.) and everyone is reflecting about the effort needed to work a given requirement. We could have two scenarios:

One: With a Clean Code Base

Clean Code estimates

Two: With a Bad (dirty) Code Base

Bad Code estimates

Imaging your code base as a tool’s repository, those tools are used to solve problems. Your job is to use the proper tool for each task, but you need to do that as quickly as possible. Now think what would happen if any time you enter the shop you find a mess of tools?

In order to do your job, first you need to find all required tools, you reach for the hammer, but find a screwdriver, then you find the drill on the level’s bucket, … (you fell me?)

After finding all required tools you start working on the piece of furniture, but you find that the last carpenter use nails where you expected screws. Also, he had use glue where fine nails where more appropriated. The hammer has grease on the handle and slips. The drill heads are out of order …

By the end of the day you are done with the piece, but you realize that building it from scratch will take half the time.

Too much bla, bla, bla: What should we do about this?

Put each piece / tool inside the proper drawer:

First, imagine your code base as a cabinet with many drawers, each one with a label. Depending on your design decisions labels will have words like (persistence, core logic, controllers, views, domain, tests, etc.); but no matter how your team decided to organize the code, each element must be inside the proper drawer.

You must put components where they belong in order in accordance to the team’s guidelines for the given application.

Leave pieces as clean as possible:

Now imagine a single file as the drill and its heads. Any time you use change heads you need to leave the set in proper order. Also, you should clean and grease moving parts regularly in order to extend the tool’s live and improve performance.
You must keep your components (files, classes, methods, etc.) as clean as possible both on the inside (implementation) and on the outside (public interface / contract).

Include the “cleaning” process in all your estimates:

Let me change the analogy for a moment: imaging what would happen if your preferred restaurant only estimates the cost of serving the dish to your table and cleaning up after you leave. But they “forget” to consider cost of dish-washing, kitchen cleaning cost and time, bathrooms cleaning time, etc.

So, the next time you’ll get there to eat your favorite dinner, they need to spend one hour just to start working on it because all elements were dirty and out of order. So you get served with one-hour delay. As they do all this in such a hurry, you find that the fork is dirty and the napkins have stains all over…

The same happens with software developers only estimating the “change” / “implementation” time,  and not considering the time needed to leave the solution as clean as they found it. Also they forgot the time to add / change existing documentation to reflect the changes. They do not consider the time for proper testing. Simply, they are leaving the shop dirty and tools out of order. When they need to “serve” another client they found the same problems as the lazy restaurant’s employees.