“Procrastination is productive”

Sounds crazy right? But my experiences with software development has shown me time and time again that procrastination on certain tasks can be the ‘correct’ and productive way to approach even crucially important tasks.

Please let me explain. I usually organize all my development tasks on some sort of Kanban board ordered by priority. Normally the advice is to take the top item off the list or to choose the biggest, nastiest task/’frog’. This type of approach is advocated by Brian Tracy in the mostly awesome book ‘Eat That Frog‘), and, in general, this is solid advice.

However there are times when I look at the top task and lose the will to live! Sometimes the problem seems too difficult/long/important to solve immediately. Rightly or wrongly, what I tend to do is to leave this nightmare task at the top of the list and ignore it. Instead choosing a much easier, but related, task, further down the list i.e. procrastinate.

Why? Because experience has taught me that these kind of tasks will bog the project down. I am not ready for it yet. The project is not in the right state yet. Things change. Requirements change. This is not a ‘quick win’. The decision to act on this task needs to be deferred until I am older and wiser.

Defer Important Decisions Where Possible

Now, I am not advocating always doing nothing, these tasks are usually fundamental tasks that need consideration. When a fundamentally important decision can be deferred I usually will defer. By waiting until the last minute to make a decision not only gives maximum flexibility to the project but it is also made when more knowledge about the problem has been gained. For example, if the task is a fundamental one like ‘Choose a database technology’ this raises alarm bells immediately. When the full extent of the expected solution is not known and an obvious choice is not prevalent, then this a risk which should be deferred. If I can choose not to address this task now, then I wont. For me, a solution in a case like this would be either not to choose a technology at all yet or choose a technology that I am familiar with but make sure that any implementation can be swapped out with another technology at any point i.e. procrastinate but engineer some ‘wriggle room’ (please please read Mary and Tom Poppendieck’s book ‘Lean Software Development: An Agile Toolkit‘ for some fantastic practical advice on what software development priorities should be).

Eat That Frog?

So what should one do? In software development, should we follow Brian Tracy and Eat the largest ‘frog’ (task) first or should we eat smaller, tastier ones until we get good at eating frogs and make sure that the bigger one isn’t poisonous?