You won't do it later!

Stand-ups and status meetings - plenty of crimes against code quality were committed during them. Why does it happen? Because it's easy. Because there's a social acceptance of it. Because we have got unspoken permission for doing it. Is the meeting or its form to blame? 

No, the problem is with one simple sentence: "I will do it later".

We hear it in many forms:

• "I did everything, but I will have to add some additional tests later."
• "Everything is working, but I will later redesign it a bit because it doesn't look good right now."
• "Yeah, I will refactor that later"

We hear it, we say it... and that's all.

When you are tempted to say a statement like the ones presented above, ask yourself is it important enough to be converted into a story. The story that has a chance to get to the top of your backlog in a finite time. If the answer is no, then you have to make a choice - do it now or admit out loud you won't do it at all.

It feels good to postpone refactoring/tests/re-design/etc. for later. Thanks to that we think we tell our teammates we care about code quality, we won't let it get decreased because of a task we created for later. We can perceive ourselves as a software craftsman and move on with delivery.

But the real message we send is different. Everyone knows this type of task in most cases are never done. You present yourself as a person who doesn't care or doesn't know how to care about the quality of the code. You say you have no time for doing it when the effort is the lowest - you are working on this code now, you are within the context and the scope. Any work you plan to postpone will become more time-consuming in the future.

Does it mean we should add all those tests we've got in our heads, proceed with all those refactorings and improvements we thought of?

No, it means you should not lie to yourself and your teammates. 

It's much harder to say "I won't do it" instead of "I will do it later". But by changing the statement you and your team will learn how to make such difficult choices. Thanks to this you will eventually do some of those "things for later" now. This approach helps to learn how to care about the code all the time. And how to recognize places where improvements are not worth your effort.

Perfection has to be your goal but you have to remember this is the goal you will never reach.

Anyway, isn't that software development in essence? Knowing when the code is good enough to move on?