The setup

I am nearly done on my current project, and because we are nearly the end, I have been thinking about it more than anything else. So here I was on Sunday, without a blog post written for Monday. I told so to my wife, and she said "Why don't you write about this picture? I found the idea interesting". So, as she is right (always), it is an interesting idea, here is a blog based on this picture:

Oppenheimer

Years ago, I saw an attempt to rewrite a long running framework project, which was an absolute mess inside (I collaborated into creating that mess). I wanted to give this project the codename Oppenheimer, as it would have represented a significant change, to the internals of the system. After year and half of not delivering the new version, the rewrite project got abandoned. Even when I wasn’t part of the rewrite, I got a nice lesson about trying to take big steps. It was not a total loss, as one thing that came out of it was a nice tooling to compare the output of the application (PS files) with previous versions, kind of a Golden Master (maybe without the kind).

A year or two later, I tried to untangle the mess on my own, without changing the basis of how the project worked, just cleaning it up and refactoring it, trying to eliminate circular dependencies and some bad behaviour. After a week I stopped, having really learned the ways that the system was all badly interconnected. I needed more experience and new techniques to deal with that code (disclaimer, I never had the chance to actually sink my teeth on it again).

The learning

I have mentioned before that I considered learning important. And this way, with learning and gaining new experience, a set of techniques came into my repertoire, like Seams, the Stranger Pattern, and Feature Flags. The idea is that bit by bit, you could start moving the code to a better position. Instead of the big rewrite, we are looking at taking small steps to convert the code.

Which, as it happens, works quite well with TDD and BDD. When using TDD we are already within the idea of taking small steps, rather than big ones. Even more when you use something like TCR (don’t we humans love acronyms?).

The small steps benefits

Taking small steps has quite a few advantages of taking the big step that, for me, makes development much better.

• It is quite easy to start getting some small victories that allow you to keep morale high.
• It is easy to see issues on the current direction and steer the project to a new route when needed.
• The improvements start showing in your system much earlier, even if each one is just a small improvements.

As shown in the picture above, and also on the example provided, taking the big step sometimes (most of the time?) stops you from actually moving forward at all.