My memory is awful.  Everyone teases me about this — my husband, my dad, my coworkers.  My friends will send me text messages to remind me of coffee dates.  I go where my calendar tells me, when it tells me to leave.  I take notes about everything, and would be lost at work without my hardcover notebook, Jira, and my mail inbox.

In my own defense, my memory is actually pretty good, as long as I need to remember something.  After all, I always did well on exams in school, even if I did just cram before exams (but who doesn’t?).  If I learn a new fact or get a new task, if I’m currently working on something related to it then the new information is incorporated into my memory.  If it isn’t and I don’t write it down, it’s gone.  Yes, it’s the selective memory excuse, but I argue it serves me well.  There are far too many detailed little things that can cram your head to the point where you don’t have enough room for the important stuff.   I learned a long time ago (reading the classic Getting Things Done by David Allen) to move the little things out of my brain and into a place to keep track of them.  Then I’m not up all night reviewing the list of items I need to do the next day — it’s already captured somewhere else and I can sleep soundly.

I modified the checklist idea a few years ago after reading another classic Being Geek – The Software Developer’s Handbook by Michael Lopp.  He suggested to regularly review your TODO list and adjust it as priorities change.  Using that idea, there are two types of work that I track:

1. Those little quick items that pop up frequently but aren’t related to a project but that still need to be done (review job applicants, email that document to Amanda, arrange a Jira team support meeting).  These are often too numerous to remember with the brain’s natural limit of 7 +/- 2, so I keep track of them with a simple list in my notebook.
2. Big items that I need to log hours against, bring others into, or break down into smaller tasks, I put into Jira.  Then I can pull them into my sprint board for the week and keep my boss and team up to date with what I’m working on.  And as an introverted benefit I don’t have to schedule update meetings!

It’s always a great feeling moving items to done or checking them off the list.  On those days where you’re just finishing up a bunch of little things, you still feel productive.

So why a blog post about checklists?

My current team is a highly productive, agile team.  I think it’s one of the more elite teams in our unit (it’s why I asked to be on it!).  However, I was surprised when joining that there wasn’t documentation outlining team processes.  We’re currently hiring and with concerns about on-boarding, I mentioned this during a team lead meeting because I found it difficult when I started. I want the newbie to feel productive quickly and push a change to production their first week.  But documentation and developers don’t mesh, so it was met with resistance.  Understandable — who wants to write a bunch of documents that are outdated the sprint after you write them?  And does anyone ever really read it, for all the time it takes to do it well?

I took software architecture training from Mark Richards a few years ago (highly recommended btw) and he suggested a good compromise for this common problem is to encourage checklists, and to automate them whenever possible.  Even pilots use checklists every single flight, because humans are reliably fallible.  I loved this idea, and applied it to the team I was leading.  I created a development checklist:

Development Checklist

Before checking in:

• Verify there’s a Jira issue for the item you’re checking in (and that you’re only checking in code for one issue)
• In build-all.properties verify the environment is set to devel
• Run the complete set of unit tests (Alt-F6 in Netbeans)
• Fix formatting on all changed files to follow code format standards (Alt-Shift-F in Netbeans)
• Make sure all public and protected methods have Javadoc
• Review FixBugs and Netbeans hints for potential bugs
• Remove console.log and System.out.println statements (logger.debug are ok)
• Increment build version number
• Verify spelling in comments and in variable names
• Remove commented out code
• Remove unused imports (Alt-Shift-I in Netbeans)
• Remove unused variables

While checking in:

• Verify you’re not checking in dist and .war files
• Verify you’ve added all new files to the repo
• Enter the Jira issue into the commit message
• Enter the application version number into the commit message

After checking in:

• Enter the application version number in the Jira issue
• Enter the SVN revision number in the Jira issue
• Add time spent on the Jira issue
• Change the issue status to Ready for Review

It helped junior programmers on the team understand what I was looking for when reviewing their code and progress, resolving some communication dynamics on the team.  And it even helped me — I used the list when I checked in items too!  We never automated any items on the list, but there are obvious candidates to streamline the process.

I’ve found this is a good compromise when there’s a need for documentation.  I’ve volunteered to create on-boarding documents for the team, and I think a checklist of steps from code checkout to deploy to production will help the newbie.  It’s a good sprint experiment to run at least.  I’ll let you know how it goes!