Jeanne Boyarsky

You’re learning to program. You receive a small assignment. You write under a thousand lines of code. You type it in and test. Then you add print statements or use a debugger. Maybe you get coffee. Then you puzzle over what you were thinking.

Sound familiar? And that’s just a toy problem. Work tasks and systems are far larger. Big problems take time to solve. And worse, there is too much to hold in your brain’s RAM. 

A good way to deal with this is to break the problem into small chunks. The smaller the better. If you can get that one small piece working, then you don’t have to think about it anymore and can move on to the next piece. When doing this well, you want to write automated tests for each small problem. You should also commit frequently. That gives you a rollback point when things don’t work as expected.

I remember helping out a teammate who was stuck. I asked when he had last committed, because the easiest fix would be to roll back and reapply the change. The answer was “a week ago.” Then he had two problems: the original one and that I wouldn’t help him debug a week’s worth of work.

After that experience, I ran a training session for my team on how to break tasks into smaller chunks. I was told by the senior developers that their tasks were “special” and “couldn’t possibly be broken up.” When you hear the word special in relation to a task, you should immediately be suspicious.

I decided to schedule a second meeting. Everyone was responsible for bringing an example of a “special” task, and I would help them break it up. The first example was a screen that was scheduled to take two weeks to develop. I split it up like this:

• Create a hello world screen at the right URL—no fields, just prints hello world.

• Add functionality to display a list from a database.

• Add a text area.

• Add a select pull-down.

• <A long list of more tiny tasks>

And guess what? After each of these tiny tasks, there could be a commit. This means commits could happen many times a day.

Then I was told that this could be done for screens, but file processing was “special.” Now what did I say about the word special? I split that up as well:

• Read a line from the file.

• Validate the first field, including the database call.

• Validate the second field and transform it using business logic.

• <A bunch of fields later>

• Apply the first business logic rule to all fields.

• <A bunch of rules later>

• Add a message to the queue.

Again, the task wasn’t special. If you think a task is special, pause and think about why. Often you will find this technique still applies.

Finally, a developer told me he couldn’t commit his code in any less than a week. The task wound up being reassigned to me. I did some extra committing to make a point. Counting, I committed 22 times in the 2 days it took to me complete the task. Maybe if he’d committed more frequently, it would have been done faster!