Time Management – Pomodoro Technique Summarized

Published on September 12, 2011 by wshaddix

This is my personal cheat-sheet for using the Pomodoro Technique for time management. Learned from Pomodoro Technique Illustrated: The Easy Way to Do More in Less Time. I’ll be refining and updating this post as I get more experience.

Stages

  1. Planning
    • Extract the most important activities from your backlog (Activity Inventory) and write them on your To Do Today sheet. This is your commitment for the day.
  2. Tracking
    • Set your timer for 25 minutes and start working on your first activity. Collect metrics like the number of times you get interrupted (internal and external) and how many unplanned activities you come up with during a pomodoro. Once the 25 minutes is complete, place an ‘X’ next to the activity and take a 5 minute break.
  3. Recording
    • At the end of the day record your daily observations
  4. Processing
    • Convert your daily data into information that you can measure, like the average number of interruptions you get per 25 minute timebox.
  5. Visualizing
    • Chart your daily measurements in a way that helps you see how to improve your process

Tools

To Do Today Sheet
Paper that contains today’s date, your name, and a list of your activities planned for today. You create a new one every morning

Activity Inventory Sheet
Paper that contains your name and an unsorted list of your upcoming activities in the near future. Use this same sheet day after day adding new activities and crossing out completed ones. Write the activities as a statement of result, not how (Mike emailed about status of project x, Desk cleaned, etc). Also record time due if required (7pm)

Records Sheet
Paper where you record your measured metrics each day in order to improve your process

Timer
You need some form of timer (phone app, computer app, kitchen timer, hourglass, etc)

The Process

  1. Start the day by copying the highest priority activities from your backlog to your To Do Today sheet. Also try to estimate the number of Pomodoros an activity will take to complete on the Activity Inventory Sheet. Any activity estimated at over 7 will need to be broken down into smaller Activities, each with its own estimate. You can combine multiple Activities that are estimated at 0 into one Pomodoro.
  2. Start your timer for 25 minutes and work on the highest priority activity
  3. Take a 5 minute break
  4. Re-prioritize activities if need be or continue on with the current one until 4 – 25 minute cycles are complete, then take a 30 minute break
  5. Repeat until end of day
  6. Record your daily observations onto your Records Sheet. This should be one row for each day with columns for # of pomodoros complete, avg. interruptions per pomodoro, and avg. unplanned and urgent tasks thought of during each pomodoro, avg # of pomodoro to complete the activity, and avg time an activity stays on the Activity Inventory Sheet before you handle it.

Handling Interruptions

Internal Interruptions
Interruptions that come from you, telling you to do other things than the activity you are focused on.

Accept, Record, Continue

  1. Write the new activity under the “Unplanned and Urgent” heading of your To Do Today Sheet if it must be done Today. Otherwise record it on your Activity Inventory Sheet and put a (u) beside it to show that it was unplanned and a deadline if you have one.
  2. Write an apostrophe ( ‘ ) at the end of the current activity to record the internal interruption.
  3. Continue immediately working on the current activity.

External Interruptions
Turn off email and phone (go silent) during the 25 minute pomodoro. Schedule an activity to address emails and voice mails if you have a lot of external communications coming in. For face-to-face interruptions try to reschedule the interruption for the next pomodoro so that you can stay focused and finish your current one.

Accept, Record, Continue

  1. Write the new activity under the “Unplanned and Urgent” heading of your To Do Today Sheet if it must be done Today. Otherwise record it on your Activity Inventory Sheet and put a (u) beside it to show that it was unplanned and a deadline if you have one.
  2. Write a dash ( – ) at the end of the current activity to record the external interruption.
  3. Continue immediately working on the current activity.
Inform, Negotiate, Schedule, Call Back
  1. Inform: “I’m in the middle of something”
  2. Negotiate: ”Is it OK if I come back to you on X”
  3. Schedule: Write down the activity and later plan it for a future Pomodoro
  4. Call Back: Call back as you have promised

Metrics

  1. Activity Estimate vs. Actual (helps you get better at estimating)
  2. # of Internal Interruptions (helps you get better at focusing)
  3. # of External Interruptions (helps you modify social interaction patterns for better productivity)
  4. # of Unplanned Activities (helps you get better and being thorough in your daily planning)

Improving

Kaizen (Answered every day as part of daily reflection)

  • Do I need smaller activities?
  • Am I bothered by a recurring distration?
  • Do I have unnecessary overhead in my standardized activities and personal process?

Posted in time management

No Comments

Application Exception Management and Logging

Published on March 10, 2011 by wshaddix

 

Overview

When writing a production web application I believe the most important non-functional requirement to get right is exception management and logging. With it, you are able to monitor the health of your application over time and make continuous improvements so that your clients have a great experience even when things go wrong. Without it, you can’t tell if things are working ok or not and it is embarrassing when your application’s clients are the first to inform you that you have a problem. Some of the examples I’ve found on the web are too simple to work in a real world scenario for a few reasons. First they don’t follow an actual exception management process, they simply log the error and possibly redirect the user to a generic error page. What if the request came via ajax and only a portion of the page they are viewing should be affected? What if the request came from an api client? Also I’ve not found much that works in a web farm environment where you need to consolidate and extract metrics from many web servers. It gets more complicated when you want to trend data over time so that you can do proper capacity planning and so that you can see the changes in resource usage that each new version of your application requires.

This is the first in a series of posts that cover defining and implementing an effective exception management and logging process that can be used to track and trend the health of your application over time.

The Process

A good exception management process includes the following:

  1. Log the technical exception along with any available contextual data in order to have the right information to figure out what went wrong as quickly as possible. If at all possible you want to know who the calling client is, what ip address they came from, what parameters they sent into your application (either via the api, web forms, or ajax request), a stack trace, and what the actual exception was. It’s also important to know any identifying information (id values) as well as information that may be contained in any database constraints. For example, if you have a series of unique constraint violations it isn’t enough to just know that the violation occurred, you need to know the actual value that is causing the violation in order to make it easier to help the client (or you!) figure out what went wrong. In addition, you want to know the hostname of the machine that the error occurred on if you are in a web farm scenario.
  2. Convert the technical exception to a user friendly explanation of what went wrong and what, if anything, can be done about it. This should include an easy way for the end-user to reference the error if they decide to contact you.
  3. Alert someone in an operational role if the error is due to failing dependencies. For example, if you are unable to access a database or a 3rd party api that is something that is not going to be fixed by you changing your application’s code. Instead it is going to require someone to bring the dependent system back online.
  4. Alert someone in a development role if the error is due to your application’s code or data inconsistencies. These errors typically are going to require a developer to take action in order to resolve the problem.
  5. Track and trend key performance indicators over time in order to prioritize bug fixes or code changes based on real-world data. These metrics include
    • How many unhandled exceptions happen over a given time period.
      • These need to be mapped to user friendly errors at a minimum. It’s better to give the end user some idea of what is happening vs. showing them an “Oops, something went wrong” error
    • How many exceptions for various categories happen over a given time period. These categories include
      • Parameter Validation Exceptions – Here you can spend more time validating input up front and/or working to make your UI more intuitive or document your api better for api clients
      • Data Integrity Exceptions – Many times these show up in the form of unique key constraint violations. With these you can do more to “pre-process” your workflows and check for uniqueness earlier in the process or with ajax validation calls in your UI. Example would be creating a username during a sign-up process where usernames have to be unique.
      • Missing Prerequisite Exceptions – These show up when prerequisites have not been met. For example if someone tries to login to your system for the first time but they have not yet validated their email address. In these cases you can look for ways to make the required sequence of events more clear to either the end user or to your api clients.
      • Timeout Exceptions – These come up when you have dependencies on other systems such as a database server or 3rd party services that you call internally. It is important to keep track of these and monitor them constantly because if  your dependencies are not available your application cannot function (queuing requests works to mitigate this as long as your queue service is available!)
      • Layer Specific Exceptions – Typically in an application that is layered you can use exception shielding at each layer which makes tracking and trending more informative. Example layer exceptions include:
        • UI Exception – An error that occurs in the UI layer
        • API Exception – An error that occurs in the API layer
        • Domain Exception – An error that occurs in the domain layer (business layer)
        • Repository Exception – An error that occurs accessing a database (data access layer)
        • Platform Exception – An error that occurs accessing a remote 3rd party api

Implementation

With the process defined we can start to focus on how we are going to implement a technical solution. The implementation will vary based on how you design your application. Specifically you may have more or less layers, you may or may not have api clients, you may or may not have browser based clients. In a future post I’m going to start building an Asp.Net MVC 3 web application that also includes an api so that we can look at the implementation details of the proposed process. Once I have the application defined and available I’ll update this section with a link to the blog post describing the implementation.

Wrap Up

As mentioned in the introduction, there is a lot more to an effective exception management policy than just using trace facilities to log an error somewhere. In the example application that I’m going to build, I’m going to build it for a production environment which means it will be running on multiple web servers and will therefore require that we have a way to centralize, parse, trend, and visualize the various metrics that we are interested in tracking.

Your application’s clients can be of at least two varieties that need to be handled differently. They can be real people who are interacting with your application via a web browser, or they could be applications that are integrated with you via API methods. The information and response that you return when errors happen is going to be different based on which scenario you are in. We will cover this as well in the upcoming application.

Tags:
Posted in exception management

No Comments

Learning Git

Published on February 27, 2011 by wshaddix

I’m currently learning Git as my first real working DVCS. One of the first things that I’ve noticed that I really like is that the repository is managed locally and is fully autonomous. There isn’t one “golden” copy of the codebase that everybody has to work in. I currently use Subversion daily and one of the pain points that I experience is that I have to be connected to the network to do commits (because it has to communicate with the central repository). Normally this isn’t a problem but when I’m working remotely I’ve been in situations where I want to make smaller commits and can’t because the central Subversion repo isn’t accessible.

Another thing that I like is the fact that branching is made not only easier, but the normal way to work. With Git (and I’m assuming other DVCS) more information is tracked where merging is simply a non-event. The fact that everything is a branch is easier for me to conceptualize than having on main-line of development (trunk) and then branches for various things.

I can see though that even with the relaxed restrictions where every dev has an autonomous repo, the automated build server still has to have knowledge of a “golden” copy of the repo for it to build the release and package it for deployment. In this case, as devs are confident in their local commits, they can push their changes up to the build server’s copy of the repo.

One important difference between Git and Subversion is that with Subversion, when you are done changing a file, your next step is to commit it back to the central SVN server. Git is different however … when you are done changing a file, your next step is to add that change to the staging area where you still have control over the file and changeset. Once you are happy with the staged changes then you commit to your local repository. So with SVN it’s a one step process and with Git it’s a two step process getting files changed and back in the repo.

As best I can tell so far, the master branch should always remain stable. Developers should not commit to the master branch unless the code is production ready. I think this is synonymous with what we use the trunk for in svn world.

Yet another difference between branch concepts of Git and Subversion is that in order to checkout different branches in Svn they go to different working copies or different folders and you have to svn switch back and forth between them. With Git, you are always in the same working folder and Git manages the state of the files within that working folder as you switch branches via the checkout command.

Merging in Git seems simpler to me as well. With Svn you edit the conflict and then you have to tell svn that you’ve resolved the issue before committing. With git, you only have to resolve the conflict (via pull which will try to auto-merge or fetch which is a manual merge) and then commit.

Overall I think once I get past the learning curve of the new commands and conceptual differences I will really enjoy working with Git. I’ve just signed up for Github so now I need to figure out what project to do next using Git!

Tags: , , ,
Posted in source code control

No Comments

My Developer Workstation Setup

Published on December 8, 2010 by wshaddix

I’m having to repave my developer workstation at home so I thought I’d take the time to document all of the various applications that I install and why in order to remember everything next time (I like to repave my machines about every six months) and to get feedback from others on what I’m missing that would make my life easier or recommendations for improvements on the tools that I use.

Initial Setup (Workstation Basics)

Office Type Apps

Communication

Design

Development

Code Analysis

Build Automation

Testing

Debugging

Process

Personal Preferences

Wrap Up & Thoughts

After installing everything run Windows Update until no more updates are found. Office and Sql Server will most likely pick up additional updates as well as .Net framework related software.

Some of the applications listed have prerequisites that I did not mention. Examples are Flash plugin for Firefox and Adobe AIR Runtime for TweetDeck and Balsamiq. Just install them as needed.

Tags: , ,
Posted in configuration, software

No Comments

Categories

Archives

Meta