Continuing in the series of behaviors that will make us better developers, today we talk about meeting our targets by doing exactly what have to be done, and nothing else.

As time goes we all eventually code a feature telling ourself “I should refactor/write a tool so I would go faster” or “it will make some future thing easier”. When this happens, just take a break.

I have spent five years part time on a pet game project, implementing every week something that would help me to go faster or that would make the game cooler. I have developed tons of super generic single use-case features to save time. Anything but the actual needed features. When we finally gave up we had a total count of zero completed game and one mess of super generic and cool stuff that fits no one else’s need.

When we feel that something would help us to go faster, the only wise thing to do is to create a story for it, add it in the backlog, and finish our feature without it. I know it is frustrating to have to postpone the changes when we feel that we need them right now but this is the best thing to do. We will be able to discuss it during the next backlog grooming, to weight its interest according to our colleagues’ impressions and to think about it in another state of mind.

If we ever feel the need for this tool again, then we would check the backlog to see if it is likely to be useful for at least one other story. If it is, then we can push our producer with solid arguments to increase the priority for the tool. Otherwise we would just continue without it. If we stick to these rules, we will reach the end of our projects without having lost our time.

Let’s say that a given tool needs three days to be implemented and allows to implement a feature in one day instead of two. If we do it for the first need then we will spend four days on the initial feature instead of two. For the people observing our work it is not acceptable. Also, by not planning the tool for long enough, we will certainly implement it the wrong way and we will tend to force the upcoming features to use it in order to dilute its initial cost. Everybody loses. So what should we do? We should implement it as soon as it will be used for at least four similar features, so we would spend seven cumulated days on the tool and the features instead of eight days on the features only. Easy, right? Easy and still wrong. One aspect that we, developers, tend to forgot is that building a piece of code is only a small part in the software’s life. Other parts include, and are not limited to, debugging and maintenance. When we add a tool to our software to ease something in its development, it comes at a cost far outside its initial integration.

Our job is to ask: is it worth it? Apart for the fact that I want it so bad right now, what will it cost us and what will be our gain? Who will maintain it? How long will we pay for it? When will this move be profitable? At the first use? in a week? a month? in two successfully delivered projects? How much time did I lost trying to answer all those questions?

At a design level, in any software development the need for new features or tools comes as we progress. Even if we work from a five hundred pages specification supposed to cover all the needs, we will wonder if it would not be nice to add some feature or integrate some new tools in our process. “What if our project had a flazzleblending super flopitor like this competitor?” “We should replace our unit testing framework for Currently Hype UT Framework, don’t we?” When these questions arise, it is important to integrate them smoothly in the process in order to not disrupt the work.

When we think that something must be done, the first thing to do is to bring it to the team. It may begin with an informal discussion with our team in order to quickly filter its interest, it may even be actually done on our own time to provide a prototype for others to judge the idea. However the most simple and efficient thing we can do is to add a story in the backlog. Did you find a bug? Create a story for it. Would you like some feature? Create a story for it. Do you want a refactoring? Create a damn story for it and finish what you are doing.

Thank you for reading. You may want to have a look at the previous parts of this series: be a leader, not a hero, be reliable and be precise, be meticulous.