I think most people share my dislike for doing timesheets, in the service industry it is pretty much a given that you need to track your time. If you are a consultant or contractor you need to do it in order to bill the client accurately, and if you are an in-house developer you typically do it for recovering costs from other departments. It is a lot of work just to produce a dollar figure that someone has to cough up.

Everytime timesheets are due I dread a phone call from the boss to quiz me on some aspect, and while I am not infalable there are instances where the application we use to enter timesheeting information and the reports show different figures - obviously a bug.

Overall, with a little bit of manual intervention the system works, but it could be better. Expenses aren't automated, we actually have an Excel spreadsheet that we use even though the timesheeting application was originally developed with a view to incorporating that functionality.

So why am I telling you all this? Well, at the moment I am playing around with a few ideas for new application construction techniques, in particular a consistent approach to dealing with occasionally connected client machines. And it so happens that our internal timesheeting requirements provide examples of some of the complex problems that I am trying to resolve with my approach.

My plan is to spend a little bit of my idle time gathering requirements from the various users of the system and look at how the existing system could be improved. From there I will see whether my techniques really do apply and make the situation better.

I will be sure to post screenshots from any prototypes as well as any cool snippets of as I go along - stay tuned.