Mark Gilbert's Blog

Science and technology, served light and fluffy.

Stops and Starts – Making Progress while Riding the Brakes

How can I write a major upgrade to a product over a period of 4 months, but only in 15 minute increments?  After my day job, family, church, chores, and sleep, I wasn’t left with much “free” time.  In fact, I found that time to be anything but free.  Most days, I considered even 30 uninterrupted minutes as a gift.  I needed to be able to get ramped up on it as quickly as I could to make the most of that “free” time.

As I worked through this period, I realized I was really facing two different but related challenges.  The first was that I needed to be able to leave what I was working on at nearly a moment’s notice.  The second was that I needed to be able to pick up from where I left as quickly as possible, mostly because I didn’t know when I would be pulled away again – it may be 5 minutes, it may be 60.

To meet these two challenges, I started relying heavily on two practices – keeping notes on my progress and writing good unit tests.

Very early in my professional career, I began to keep a document for each project I was working on.  The application used to manage this document has varied over time (Microsoft Word, Microsoft OneNote, and currently TextPad), but the basic format has remained the same – make a list of what I need to do, and then place details about each task indented below it:

  • Task 1
    • Detail 1
    • Detail 2
    • Error to correct
    • Something to optimize
  • Task 2
  • Task 3

To address my first challenge, I would keep a very detailed list of what I was working on, and where exactly I was in the process.  Over time I’ve developed a standard list of status messages that get tacked on to the beginning of each task:

  • TBT – To be tested; I will usually include a note below this to explain which environment (Dev, Staging, etc.) it needs to be tested.
  • OH – On hold; I will include a note below this to explain why it’s on hold – who or what am I waiting on before I can work on this item?
  • DONE – item is complete, but I need to keep it around for a later task (like documenting it, or just to remind me of the path that led me to my current predicament)

So, my task list might look something like this:

  • Task 1
    • Detail 1
    • (DONE) Detail 2
    • Error to correct
    • (OH) Something to optimize
      • Need to fix the error above
  • (TBT) Task 2
    • Test on Dev
    • Test on Stage
  • Task 3

This becomes absolutely critical when it comes to debugging.  If I get stuck on a bug or some other problem, I will make lots of notes documenting links to web pages that contain a possible solution, list of things I’ve tried (and whether they helped or not), things to check in the code, and so on.  Some of my debugging sessions span days, and being able to skim through a list of my 15 previous attempts in the first minute of my 15 allows me to quickly jump into another round.

The other technique I would use to document where I’ve left off and especially to give me a place to pick up is with my test suites.  For projects where I am the only one to be working on it (namely those that I am working on in my “free” time), I will sometimes leave the work with a failing test.  When I return to the project, my habit is to do a fresh build and run the entire test suite.  I would see the one failing test, and immediately have something to do.  Working through that test gets my mind back into the code.

For projects where other people will be working on the same source code (namely those that I am working during my day job), I couldn’t afford to let them pull down source code that broke a test right out of the gate.  In those cases I may write the test and then comment it out with a note saying “this is the next test to write code for”, or I may just leave a TODO in the test suite documenting what my next test should look like.

These two techniques help to minimize the starts and stops in my projects. They require a good amount of time and discipline, but they pay back in spades when I get only get 15 minutes to make something happen.

Come on, Lucy, stay asleep for just 5 more minutes!


March 22, 2010 - Posted by | General

1 Comment

  1. […] in Visual Studio/.NET. trackback One of my two long-term “home” projects (the ones that I do 15-minutes at a time) is called Assistant and requires a “plug-in” architecture, meaning you write to an interface, […]

    Pingback by This one, not THAT one! AppDomains, Dynamic Assembly Loading, and the AssemblyResolve event. « Mark Gilbert’s Blog | March 25, 2010

Sorry, the comment form is closed at this time.

%d bloggers like this: