I’ve talked about why smaller is better and especially why this pertains to product backlogs, or rather fatlogs, but I wanted to zoom in for a second to one of the most valuable applications of the rule: writing the code.

Typical workflow

What do you do when you get a task or a backlog item to work on?  Do you just pick a starting point and start writing code?  Do you break it down into a few pieces and start working on one?

It probably depends on the size of the work.

When I run into an item that is sized a little too large, problem admiration can set in if I am not careful.

What is problem admiration?  It is when the problem you are trying to solve seems too big and overwhelming, that you just sit and stare at it instead of attacking it.

This can be a really big problem if you don’t have a good workflow that tackles it.

Winning the battle

So how do we combat this problem?

One of the strategies I use, is very similar to a mini-agile process in the agile process. 

When I am working on a piece of functionality, I will have my own sticky notes nearby.

I’ll slice up my work, whether it be a task or a backlog, into distinct pieces of work that need to be done.  I’ll even write a few different units of work on a single sticky note.

I might have a sticky note that says “localize the screen.”  Or one that says “recheck unit tests to make sure they are accurate.”  Or “Populate drop down x.”

Sometimes I refine the notes and break them down further.  My goal is always to get the current task at hand to such a small difficulty that I can easily accomplish it.

You are always much more effective doing many easy tasks rather than trying to do few difficult tasks.

As I accomplish a task, I cross it off the list.

If I think of a new task, I add it to the list.

Why is this so important?

In general, developers, or rather humans, share a weakness of having a hard time accomplishing something that is large and not fully understood.

I have seen some very knowledgeable and skilled developers that were never successful, because they could never push through and get things done.

Time and time again I have seen them become paralyzed by the work that needed to be done instead of actually doing it.

You might not have this problem in general, but you would probably be lying if you said you don’t suffer from it from time to time.

You might not even recognize it.  It might show up as a lack of motivation, or “burn out.”

Many times when I don’t break down the tasks into smaller pieces I have a tendency to overlook some part of the work that needed to be done, because I either forgot about or didn’t take the time to consider it.

If you take the time to break apart your work into very small pieces, you will probably find, you are more motivated to get the work done, feel like you have a better direction in which to go, and will miss fewer requirements.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

John Sonmez