{get; set;} : CODE!

I’ve been quiet for a while because I’ve been working on a pet project: VSTime. It’s finally ready to try out and is available at http://vstime.codeplex.com.

What it Does

VSTime is a simple little Visual Studio plugin that records events such as file opening, compiling, and debugging. It tallies up all that time spent doing those individual things and presents a report. You can see how much time you spent editing files, building, and debugging, and a total time spent on a solution.

I hope that this utility will be useful to developers in measuring the time you spend actually doing the rubber-to-road work of development. I hope no pointy-haired managers get it in their heads that this tool can or should be used to measure productivity. It can’t and won’t, so don’t try.

However, if your pointy-haired manager insists that a 386 with 256MB of RAM should be plenty, don’t be shy about showing him/her how most of your time is spent building/compiling your projects. Graphs like the one in VSTime could be very effective that way!

Design

I agonized over some of the design decisions, most especially the method for persisting the event records. I finally settled on SQL Server 2005 Express for two primary reasons:

1. If you have Visual Studio 2008 installed, SQL Server 2005 Express is installed by default.
2. The row_number function in SQL 2005 makes tallying the time of each event rather easy.

VSTime is designed in a way that should make it easy to plug in a different persistence layer. I may develop a SQL Compact or SQLite-based DAL plugin in the future.

VSTime takes advantage of the EnvDTE.DTE interface, which is the wrapped COM interface that represents the Visual Studio IDE automation object model. EnvDTE.DTE exposes an Events interface, which in turn exposes a bundle of interesting events, including Solution, Window, Build, and Debug -related events.

How It Works

Each of the events, including file open, build, debug, and a few others, is recorded to an EventRecord table. The duration of an event is the time it occurs to the time the next event is recorded. So, for example, if a file is opened at 12:00.00 and then the project is built at 12:05.00, then that file has been “active” for five minutes. The action of the next event “ends” the current event. If the user then goes back to the file, the WindowActivated event is registered and time begins to accrue on that file again.

If you walk away from your desk for a break, an idle counter kicks off after five minutes of no activity. This records an IDLE event, and the duration of IDLE events are filtered out in the reporting. If you are editing a file, a keyboard event resets the counter each time you hit the Enter key. The idle timer is hardcoded at the moment. I have set up a work item to make it configurable.

You can view the time spent on the currently-opened solution by selecting Tools-VSTime. Like the little stopwatch in the menu? It’s the extent of my artistic ability

The first tab of the VSTime ToolWindow displays a grid of the time spent on each activity, in descending order. Based on my experience, you will likely find a file or two (or more) at the top that contains all the important stuff, with lesser files, debugging, and building further down. This of course will depend on your usage patterns and the nature of your projects.

The second tab displays a horizontal graph of all the events. You can zoom in on the events by drag-selecting an area of the graph. Zoom back out by clicking the little button above the scrollbar.

Data

The VSTime database is very simple. There are two tables: Solution and EventRecord. Each EventRecord relates to a Solution. As explained above, Event duration is defined as the moment an event occurs to the to moment of the subsequent event. I believe this is effective, but there are some issues.

The primary issue to be aware of is that it is possible to edit a file while debugging in Visual Studio. This means that you could be, in practical terms, “Debugging” and editing a file at the same time. The Solution Total Time will still be accurate, because the act of activating a file window will “end” the debugging event. However, VSTime does not currently support the idea of concurrent events, so your event time tallies for Debugging may be off if you often edit files while debugging.

Future Development

Support for VS 2010 is planned and will be in the next release. I don’t think I’ll be spending any time on VS 2005 compatibility, but if there is tons of interest I may reconsider. Future releases will include more tests. I’m also looking into the possiblity of tracking additional interesting events such as source control commits.

Yes, It’s Open Source

Please try out VSTime if you think you’ll find it useful. If you love it/like it/hate it, don’t be shy. Post here or on Codeplex. Tell the world what you like/hate about it. If you’re really passionate about it either way, get involved and make suggestions or even post a patch!