Knowing what is required to complete a programming task can be a black art, unless some thought is used.  This can be observed by how frequently engineers complete 90% of a task to only then spend a further significant period of time finishing the last elusive 10% of the task.  In the worst cases that final 10% can account for 90% of the duration of the task, which takes the task duration way over the initial estimate.

I think a lot of this underestimation of task length comes down to engineers not having an idea of what being done looks like for the task they are attempting.  Here is some guidelines I use, note that implementation does not take up a lot of space: the list is mostly focused on what is required before and after implementation.  These guidelines are not perfect and I sometimes forget or skip some points depending on the scale of the task:

  • Design
    • Is the User Story (or requirements) accurate?
    • Has a brief design been created in some form e.g. notebook, whiteboard or electronically with at least:
      • The User story (or requirements), a sentence or two.
      • Solution summary, a paragraph or two.
      • A sketch of the solution.
      • Technical notes, if required.
    • Has the design been peer reviewed, remember its cheapest to fix bugs at the requirements and design phase.
  • Planning
    • Initial task estimation.
    • Break the task down into sub-tasks (if required).
    • Estimate duration for each sub-task.
    • Scheduling.
  • Implementation
    • Have all the sub tasks or features been completed.
    • Has any duplication that has been generated been refactored?
  • Testing
    • Have unit tests been added or updated for the new feature.
    • Has the executing program code been walked through in a debugger?
    • Has the end user reviewed the finished feature?
  • Review
    • Has every file that is about to be checked in been compared to its previous version with a difference tool to confirm the changes to the file are the changes that are required.
    • Has the code been code reviewed by a peer.
    • Has the code been analysed with:
  • Check in
    • Remove any unchanged files from the change list.
    • Remove any temporary hacks from the change list e.g, for configuration or testing purposes.
    • Check that all files that need to be added/removed from source control are included.
    • If possible confirm the code builds on a separate test computer before checking in, to make sure no files are missing.

I’m still pondering ‘What done looks like’ so I’ll probably revisit and revise this list at some point in the future, as I’d really like to develop a simple check list I can use to educate more junior engineers.