Development Logs

August 8, 2012

As I have been learning the craft of software development, I have naturally had the occasional stumble along the way. Making mistakes is fine. Learning from mistakes is great! Repeating the same mistakes is disheartening. Unfortunately, I’ve fallen into the trap of not remembering better approaches to familiar problems. Why is that? …because I haven’t been documenting my decision-making.

###Missing the Estimate On my most recent iteration, I had two primary stories. I estimated that they wouldn’t take more than a couple of days each. On the first story, I ran into trouble almost right away. I misjudged the amount of change necessary to fulfill the story requirements. As a result, I ended up exceeding the pessimistic estimate I gave at the start of the iteration. Everyone tells me that estimating is difficult. However, that doesn’t mean I can’t improve on it. Every missed estimate holds a lesson to learn.

On the second story, I decided that I wanted to know where my time was going. To track my activities, I started an outline-like log of the changes I was making. Each item listed the class being modified, the tests being written (which described the change being made), and the motivation for the change. When I had unforeseen difficulties, they were detailed as they occurred along with the solutions I found to overcome them.

###Logs By the time I was done, I had a near-complete breakdown of not only what I did, but where my mind was along the way. It helped keep the goal in focus, which in turn helped to manage my pace. Perhaps as a byproduct of this, or simply as the result of overestimation, the story was completed in less time than assigned to my optimistic estimate. Again, I wanted to know what was really going on here. The answer resides in the log.

The notes I took didn’t indicate any time sinks, distractions, or other unexpected challenges, which I am encouraged to include in future logs. Everything progressed like clockwork. There isn’t as much value in this case as there would have been if I had logged the previous story. The contrast between “everything went right” and “everything went wrong” is an invaluable learning tool. As I continue with future stories, I intend on having a clear record of why my estimates were over, under, or right on target.

###What Went Right/Wrong, or What I Predicted/Missed One more thing I’ll do with my logs is include a miniature postmortem of sorts. I’ll briefly summarize the major points of learning which I can apply towards future estimates. Understanding my development process in this depth will inform not only my estimates, but the decisions made in every aspect of software development.

< Testing Execution Order