I have wanted to refactor some code at work for some time now. Several teammates agree with me, and I clearly know what I need to do. The problem is that this refactor will result in several thousand changed lines, and, of course, I can’t just send it to anyone for review. Therefore, I spent a few weeks creating a series of small changes that will eventually resolve into the refactor I originally wanted.
Many people are surprised I can invest time like this in such a refactor. Many software development teams go from sprint to sprint without ever stopping to breathe in between; they spend all their time resolving “user stories” under a project manager who only knows how to add up story points and whose catchphrases are “you always want to refactor stuff,” “you need to learn the difference between what’s urgent and what’s important,” and “always with that nonsense about technical debt.”
“The secret of my productivity is that I keep my eye on my target and don’t let myself get distracted by whatever obstacles I find on my path.”
This pace is not sustainable in the long term: it’s like a shoe store whose owners want to spend all the time selling shoes, from opening to closing time, not leaving any time for cleaning and tidying up and ordering more shoes to sell the next day. After only three days, that store would be filthy, and its shelves would be empty.
It is essential to include time for contingencies and maintenance during project planning, and that’s equally true whether we use a waterfall lifecycle or an Agile methodology. The reasons are straightforward: for one, it is inevitable to introduce bugs, and when they keep the program from running correctly, they need to be fixed, which takes time.
Even in the absence of bugs, the first version of the code is often unsuitable, which forces us to modify or even redesign it. Doing this, once again, takes time. If nobody allocates any time for it, these changes will delay the project because they will consume some of the time we had expected to use for all the other things we had scheduled.
You also need to reserve some time for training. I’m not talking about classes and conferences but about writing prototypes and reading documentation. When a rally driver runs a race, that’s not the first time they are taking their car on that circuit: they have already driven it a few other times before to take notes and study the curves and so be able to run as fast as possible on race day.
However, many people expect programmers to be able to write a complex program on the first try. In practice, the first version is often useless, which requires building a new one, again causing delays. It would be better to schedule some time for a prototype before the actual implementation.
It’s often hard to justify that extra time in the budget, especially for hourly contractors or teams with Agile methodologies that emphasize sprinting, delivering user stories, and resolving so many points per sprint. However, it’s worth fighting for it because, in the end, it doesn’t matter whether anyone accounted for that time in the project planning; it will be used anyway. You choose what you will deliver after six months: a six-month project delivered on time or a four-month project with a two-month delay. Both will take exactly as long, but only one will enhance the team’s reputation and morale. Care to guess which one?
The illustration for this Coding Sheet is an engraving by José Guadalupe Posada.