Channels ▼
RSS

Design

Leave Breadcrumbs For Yourself


The good people at InformIT (the website for the overlords of Addison-Wesley, Prentice-Hall, Que Books, and many of the top publishers of programming books) have asked me to participate in an occasional series they run called "Best Programming Advice I Ever Got." The title evokes the image of a wise programmer passing on to me a key insight that changed me (young grasshopper!) for the better. But in fact, most of the practices I would pull on are the results of discovering them in the field or in the literature, without the benefit of sagacious instruction. Certainly, the practice that has most changed and most improved my programming is unit testing. Unit testing long predates the Agile crowd discovery of it. But it was the agilists, notably Kent Beck, who provided the tools that made it super easy to incorporate unit tests into programming. Thanks to his work, I have spent far, far less time in debuggers than I once did.

But I don't remember how I came to appreciate unit testing. The next most useful thing I can think of us is a habit I've cultivated over the years that has been an enormous time saver. Unlike unit testing, I believe far fewer developers are familiar with this helpful habit: When I finish programming for the day, I spend several moments writing down the last thing I was doing, what I hoped to do next (and the file involved), and whatever other information I might find useful when I resume work on this project. Here is the current entry, which I invariably keep in a file named "nextsteps.txt" (which I do check into the VCS):

LineParser.java: finish handling the commands. (Already done the block comments and macros.)

  • design work on how to do command substitution
  • implement all command types except Symbol, Command0, and CommandS, which have been implemented.
  • finish CommandTable
  • unit tests for CommandTable

These entries reveal an active moment in a project migration. A class, whose name I carefully give, needs the command processor to be completed. To do that, I have to design a feature. I also have to finish one of the known, needed components (the command table). I need the unit tests for the command table brought over and validated. And finally, I have to implement processing for some remaining command types.

In less than 50 words, I have given myself context, file names, next steps, and what steps those next steps were a part of. Not bad. When I resume this project tomorrow, I'll know exactly where and how to dive back in. Should I need to see exactly what I did last, of course, I can look it up in the VCS.

Note that most of the items on the list are too small to be recorded in the defect tracker/task system (DTS). These are really personal entries that are part of something that will appear later in the tracker. I don't recommend that these notes go into the DTS as "work update" notes because defect tracker notes should record what's been done, rather than the next step to be done.

Over time, my list of breadcrumbs grows. This happens because sometimes, when I jump back into a project, I'm called to fix an unexpected bug in an entirely different area. In such cases, the notes I've made become even more valuable when I return to what I was doing previously. However, what occasionally will happen is that the bit I was working on is pushed down three or four times and the to-do items at the bottom start becoming quite old.

At that point, I move the older items out of my personal tracking file and put them into the DTS. If I'm not actively working on them, it makes no sense for me to keep the information to myself. I add them sometimes purely as progress history notes, other times as a new sub-task in an existing task — it really depends on context. This step enables someone else to pick up the ball and have all the information they need without having to ask a lot of questions or read a lot of code.

Unlike many other coding practices — such as unit testing, which still is dismissed by some developers—I've never met anyone who systemically left breadcrumbs for themself and eventually abandoned the practice. It's a tremendous time saver that mostly benefits you, but can greatly help teammates if they have to pick up a thread you were previously working on.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video