How I Spent My Time at Work the Past 7 Weeks

Over the past 7 weeks between 8/6/2007 and the end 9/21/2007 I conducted an experiment in which I tracked time spent on different tasks at work. Weeks were considered between 7:30 AM and 6:00 PM Monday through Friday. Overtime was not considered. The summaries are given below as a percentage of total time tracked for that particular week. For example, if I only tracked 30 hours worth of tasks during a week, then time spent per task was calculated as a percentage of 30 hours.

My goal is to gain a deeper understanding of the software development process at my organization, to quantify assertions I hold regarding my activities, and to empirically measure changes by way of historical context.

Below are the summarized categories over the 7 weeks with a short description:

Development: 48%
Development is the task of software construction. I count development time as reading, writing, or debugging code.

Customer Support: 12%
Customer support related tasks are counted as the time I spend on requests initiated by our customers. This generally involves communication and log mining activities.

Time in the ROC: 08%
Due to the secure nature in which we must conduct business, all access to our production machines must be done in a secure location known as the remote operations center or ROC.

Meetings: 07%
No explanation needed.

Report generation: 05%
Creating both internal and customer reports.

Team Help: 05%
Receiving or giving help on specific technical issues. Team meetings were not categorized here.

Design: 04%
Software design activities.

Conference Calls: 03%
No explanation needed.

Testing: 02%
Software testing activities.

Integration: 02%
Development time spent integrating our software product into a customer's system.

Requirements: 01%
Requirements gathering activities.

Email: 01%
Responding to email messages.

Documentation: 01%
Writing technical documentation.

Releasing code: <1%
Releasing new code into our production environment.

Help desk: <1%
Internal help desk requests.

* * *

Analysis

Development Time
I was surprised to see how much time I actually spent time writing code. Although I am a software developer, my perception was way off from what the actual data shows. I think that any developer spending almost half of his or her time coding is pretty good. One factor that may be altering my development time perception is the number of interruptions incurred when coding, I may track this in the future.

Customer Support
This was fairly low but if I was a manager, I would keep a close eye on how much customer support my developers are providing. If it gets up around 15% to 20% it may be time to hire or train level 1 support personnel. Customer support specialists will always be less expensive than software developers.

Meetings & Telephone Calls
As a general rule I dislike meetings and conference calls. My company has a weekly staff meeting every Monday for 30 minuets to get everyone on the same page. I feel that very little if any of my time is wasted in meetings. When we do meet, an agenda is followed and everyone stays on topic. While we are not quite the model of a Manager Tools meeting, I think that we still score an A- when it comes to meetings. Kudos to excellent management.

Telephone calls are a different story. While 3% may seem like a small number, nothing is more effective at getting me off track than a telephone call. A conference call with a customer is rarely a discussion on the thing I just happen to be working on and usually a call requires me to spend a short amount of time preparing. While the call may only be 20 minuets, there may be action items and/or new priorities that cause further disturbance in my schedule.

Requirements and Design
After some reflection on the proportionally small amount of time I spent on requirements, I conclude that most of the requirements have been either already well defined or self-evident (bug fixes). While my role is not that of a systems analyst, I was a bit surprised at how little time I spent thinking about requirements.

Design is another matter. For better or worse most of my design happens as I am coding. There have been a few exceptions to this, however the design while you code methodology is certainly the norm. Coming from a software engineering background this was a red flag and is a topic I will be meditating on in the future.


Conclusions

This was an extremely interesting endeavor for me. I am looking forward to the feedback I receive when I give this data to management. Going forward, I plan to continue tracking my times and refining my methods (mostly self-discipline).