How important are development Time Entries?

Question

Hi, for my final year project (BSc Software Engineering) I am looking at time entries for software applications, and whether they accurately reflect the development of the project, and whether they can be improved or automated.

For this I will be prototyping a plug-in for Visual Studio using VSPackages that will automatically track which files are being worked on, assigning the files to tasks and projects. The plug-in will also track periods of inactivity within Visual Studio.

This will then be backed up via a simple Web Application for non-technical staff to pull reports from, so that projects can be tracked very accurately.

I currently work in a small company (10 people) and cannot get the large set of data I need to gain a good conclusion from. For this reason I ask if it would be possible to discuss the topic below and if you have a few spare minutes to fill in my questionnaire and email me the result to the address contained within the document:

http://www.mediafire.com/?dmrqmwknmty

Cheers, MiG

Answer 1

In answer to your question, development time entries are important. But you can't measure them through a single IDE, nor indeed through any software. The development process is a complex one involving discussions, planning around a whiteboard, diagrams sketched on a piece of paper, research on the Internet, etc etc.

Read Jeff Atwood's excellent post on laziness and the other posts he refers to there. A good, successful developer spends time away from the IDE making sure they don't spend 90% of their working day reinventing the wheel, or 50% of their day heading down the wrong track because they haven't thought the design through.

Answer 2

I find the basic idea interesting, even though automated time tracking has flaws, just as measuring the number and frequency of commits to a project (as done on ohloh.net for example) can be a very misleading indicator about its activity.

However, the reality is that time worked is the basis for billing, and needs to be measured somehow. There are already solutions for this, though.

Take a look at

• Grindstone or
• AllNetic Working Time Tracker

(there are many more out there but these two I know well).

They work independently from what tool(s)/IDEs I am using, they can detect my absence/presence on the computer and prompt me about how I want to file the time, and they can do all the necessary reporting. It is also easy to add and manage filed entries.

What would your Visual Studio Plugin achieve that these solutions don't offer already?

Answer 3

A bit off track, but you could potentially use this sort of data to illuminate areas of complexity (LOC), areas that are prone to change (frequent updates 'n' days apart), etc. but even this would be skewed by different programmers approaches to development.

Answer 4

Time spent developing in an IDE provides only a (sometimes very) partial metric of how much time a developer works.

I have been using FogBugz version 7 lately at work, and it has a feature that allows developers to estimate how long it will take them to finish a case. The developer can then use the software to say, "I am working on this case". Then the clock will count down until it reaches zero, based on the developer's working schedule (including days off), the hours that they say they are in the office, and the percentage of their time that they estimate they are working on cases.

But as a developer, I know that I can easily get sidetracked by more important cases. I also know that I spend a good deal of time working on the cases using tools other than the IDE - such as testing in MbUnit, looking for error message explanations online, or giving status to people who ask me why I have not finished working on a bug yet. And I've also been in places where I spent half the typical day - or more - in meetings or in a lab doing my work on a remote machine somewhere else. When I'm at my desk, I could be using my computer to map out ideas for the work I'm doing, or just pen and paper.

So there are a lot of variables to consider when you ask the question, "Is the guy who sits over there really doing his work?" You would really need to look at more running applications than just Visual Studio 2008 (devenv.exe). You would probably need to look at activity for processes associated with a developer's test framework, text documents, remote desktop connections to other machines, and even Firefox. (Firefox would be a huge judgment call as to whether somebody is actually working!)

As part of your research for the project, I would also suggest researching some of the other time collection systems that are in use throughout your company's industry and comparing their features.

Answer 5

We track all our time by project daily. It takes me less than five minutes a day to fill out what I was working on. This is not something that can be automated or even should be automated as it will never be anywhere close to accurate. Files aren't always associated with just one project and it would cost me more time to tell an application which files belong to which project that the five minutes it takes to fill our my timesheet. No one spends the entire day typing - there are meetings and phone calls and thinking (you know where you figure out what you want to type!), none of that will be captured in your automated system. What you are porposing will not be more accurate, it will be less accurate than requiring people fill in time sheets daily.

Answer 6

While time entries are important, figuring out how to organize it is where trouble comes into the picture. How well would non-technical staff understand the various phases of development in order to understand the data? I'll agree with the other responses that the IDE tracking is a terrible idea, especially if part of what is being done involves changing a database through a web browser which is what I have in my current big CMS project where we may have to change templates or create content to test out if the functionality works.

This also heavily ignores the gaming the system idea that can happen. What if I leave my IDE open in debug because I'm wanting to scan memory or do something else that requires the window be open to actually look at something but I could also have left my desk unless you are somehow tracking where I'm looking and sitting.