The other day, I made co-workers feel the meaning of these words.

From time to time, we do mob-programming. We use TDD (or BDD), and we work together in critical parts that we all will work later.

Just a few days ago, we had to do a big refactor. Something that felt crazy, that had to change countless things, and that could potentially break plenty of things.

Because I have the faster PC, I often host the sessions —tests execute around 2 and 20 times faster—. And I took the advantage to make a bold movement.

I already knew that the sooner we make something work, although it is not perfect —or even it is far from perfect—, the easier it is to continue developing step by step. So, against the will of the other senior engineer (close co-worker for more than six years), I decided to do a quick and filthy change. That change kept all the old code working, and at the same time, made possible the progressive transformation of the towards the final architecture.

When my old buddy complained —as I expected—, I just told him: «ok, instead of reverting this, why not we clean now the code?». Something clicked at that moment in him because I felt that he understood that.

At that moment, we started doing a succession of fast small-changes that in just two hours changed the architecture and the refactor was finished, allowing future developments to land more softly.

Thanks to that approach, we spend a couple of hours instead of the several days that we feared.

I already did those kinds of bold changes before, but it was the first time that the team deeply understood what I meant by "Make it work first".

Sometimes the words are easy to say, but harder to understand unless you practice them to the last consequence ;)

Thanks Javier!