Developing timesheet software is simple...
right?

There is no question that timesheeting feels
like something that should be simple to develop because it should be simple to use.

Unfortunately sometimes the simpler something needs to be, the more work that has to go into
it, and nowhere is this more true that in time management software.

Why is it so difficult to create a 'simple' timesheet?

Before we created TimeFiler, we’d seen numerous attempts at creating ‘simple timesheet software’. They all became unstuck because they were treated much like some other bread and butter issue on a developers task list.

So we decided if we were serious about a new breed of time management, then we were going to have to expect to write a lot of code.

The core of the timesheet is the time entry area. Most likely, you’ll want to use it for almost all employees in your company. If it’s great to use, employees are happy. If it totally sucks, you are no longer creating employee happiness. And if it’s 2x, 4x, 10x harder to use than something else, then it is costing your business dearly, and the cost to develop it internally is likely to be the tiniest of the extra costs to the business.

For TimeFiler, the immediate core code behind our time entry area amounts to around 60,000 lines. If you count the manager views, then we are talking around 100,000 lines. And that’s not counting the supporting functionality it will call such as the integrated business rule engine, or the reporting framework to print off a manager view for example.

100,000 lines is a decent amount of code (especially for what looks like ‘just one screen’), yet it is all code that must be there. We don’t write code for the sake of it as much as coding can be fun. And remember this is just one part of the system. TimeFiler is definitely a lot more than 100,000 lines of code!

It’s sometimes hard to draw comparisons
between different languages and environments, but it’s safe to say that whatever environment
you choose, there will be no silver bullet other than investing a lot of time, passion and
resource into getting this working well in a way
that doesn’t take you backwards.

Don’t ever assume that automation won’t necessarily take you backwards.

Let's get into the nitty-gritty.

Let's take a look at the timeband grid in the timesheet. That’s the one whose primary focus is for customers who want to be recording start and end time for at least some of their employees.

Let’s think about the first problem… start and end times. These are notoriously difficult to get right and deal with the little quirks that people will use and expect to be recognised with entering time. For example:

• The end time should adjust if it’s less than the start time (because they are probably meaning 15:00 and not 03:00 for example)
• We’ve got to be able to handle post-midnight situations without people having to also supply a date (not a good idea). None of this is easily developed using out of the box tools.

And what amount of time does this actually represent that would end up being paid for example? If you enter 9:00 – 17:00, then in most cases an unpaid break will be involved, and in some cases more than one break. The timing of the breakhas a bearing on exactly what the employee is going to be paid.

Some clients don’t need to specify things in terms of start and end time, and only a quantity is needed. You’ve generally still got to worry about rounding, and presenting this quantity in a way that suits fast timesheet entry. Overriding key strokes so that they can use the enter and arrow keys make a huge difference.

What about all the other pieces of information that need to be captured?

Often you’ll be recording other information too. For example an absence reason, or a job or activity etc. There could be bunch of things you need to record, and we could be talking about different kinds of things for different groups of employees.

Now this is where things can get tricky… Let’s say you have a potential list of a few thousand jobs that the employee can select from. The web hasn’t been suited to dealing with this in the past, and many basic timesheets don’t handle it well because they are used to sending this information down every time the timesheet ‘is drawn’ and changed. You can tell which ones they are because they generally use vanilla combo looking controls. TimeFiler doesn’t work like that at all. Jobs can be incrementally searched using Ajax techniques, and the list of results will narrow as you type. It doesn’t really matter how many jobs your company has. It has no effect on performance in TimeFiler.

And there can be some interplay between different kinds of things you might want to record. For example interplay between clients, and jobs, and/or jobs and activities. For example choose a chargeable job, and you’ll only see chargeable activities and vice versa.

If you are a company that mainly enters time as quantities then it is usually best to lay out this entry area in more of a cross tab format. By that we mean that the days in the timesheet period are columns, and you enter in say job/activity in the left hand side and the quantities in those day columns. The reason for this is that it severely reduces data entry time because if a row contains a particular job and activity, then for each quantity you are adding into that row, you don’t have to reselect the same job and activity.

Unfortunately for anyone who develops the quantity entry grid this way, they will discover that it is extremely difficult to get right.
The way the data needs to be displayed and edited is basically completely different to the
way it is stored in the database. We’ve
succeeded after spending a lot of time on it, and several evolutions.

Additionally most clients will want their employees to be
able to attach comments and notes. Usually screen space is scarce, so we’ve found most clients like to just show the presence of a note with a paperclip, and hover over to see and modify notes. This starts to get tricky from a development point of view, because it is the start of managing entry data where what the employee sees, is really a twisted view of a huge amount of data that must be held to render their timesheet correctly and immediately as it changes during input.

Why is this so difficult?

As an employee keys in entries, the time entry area should be showing totals. The feedback should be immediate. This is surprisingly tricky for web applications; not many do this well. The tricky part of this is that often you will want totals that include information outside of the timesheet period you are entering, or it might straddle it. Or you might want to total just certain things. For example a column of leave payment totals versus meal allowances etc. In all cases this should be soft coded, ie configurable, because it will eventually change.

As well as showing totals in the editing area, you may have other areas in the timesheet which also show totals based on what you are keying in, and perhaps totals of past information for comparison. Again, these should all update as you type for immediate feedback. The reason for these different totals is that they can provide a different view of the time entry information. For example there may be a summary view that is about a day by day breakdown of calculated payments. And then there could be another view that summarises it even further.

We’ve just talked about calculated payments. Of course this can only happen if there is a business rule engine that can take the payment and other conditions of your employees and calculate them in a split second as employee keys in their times. Now because this is immediate feedback, all the data required to figure these payments out has to have been loaded from the database when you are looking at their timesheet, and this all needs to be juggled in memory.

And it needs to be able to fit hand in glove with the web code that knows which rows in any of the grids need to be updated. This is because with the web you need to careful about how much is being sent to the browser. So to update the entry areas after their timesheet has been recalculated, we only send down the differences. This is good for performance, but tricky.

The business rule engine can do more than just process payments. It can also figure out if any rules have been broken and provide meaningful warnings with both colours and hints. This all happens in real time, and yet again the business rule engine will very often need to refer to information that isn’t shown in the entry areas. For example employee details, public holiday information, previous transactions, and even their roster. As with payments, we need to be careful about only sending down the rows that have changed.

And the timesheet entry area should be more than just thinking about purely time that actually occurred. It is also a good place to deal with leave requests, their regular roster along with any overrides to it, as well as employee availability. At the end of the day there are huge similarities between these topics even if some of them start to have a cyclic aspect. If you start recording roster work patterns, you’ll also want the timesheet to be able to show those at any point in time.

So all of this so far has involved a lot of work and care to get right.

Understanding the big picture

But the timesheet shouldn’t need to always
work in isolation. For example employees might
be happy to have the whole screen as their timesheet, but if you were a manager and you were flicking through timesheets, wouldn’t you want to see a bird's eye view of all your employee
timesheets, and then see their specific timesheet when you clicked into it?

And if you were looking that this timesheet, then surely it would be much better if that timesheet was exactly the same looking timesheet as what the employee submitted?

This was exactly the kind of problem we have had to solve, and under a web environment it is extremely hard to get right.

The manager view is a bird’s eye view of all your timesheets. It must be configured according to what is best for your managers, and this could vary. When looking at an employee for a date, it should show the timesheet that it relates to underneath.

Things should be very dynamic between the two views. If there are warnings in the timesheet, then they should show in the manager view. If the manager fixes those warnings in the timesheet and saves it, then the manager view should now immediately reflect that. In fact any changes you make to the timesheet should be immediately updated in the manager view area after the timesheet has been saved.

Final thoughts

So this should give you a feel for what you are up against if you are about to embark on the journey towards developing your own timesheet system. And we haven’t really talked about reporting, or getting the transactions out into other systems, or maintaining your data, or synchronizing from elsewhere.

We’re not trying to unnecessarily alarm you, and there may very well be decent enough reasons for writing your own system. But we think for the vast majority of customers, their needs can be met by commercial software and TimeFiler in particular. At the very least you should have a better idea of what needs to go on ‘under the hood’ to create something that your employees will love and see as ‘simple’.

 

Avoiding vendor lock-in

Try TimeFiler now

Enquire now

Newsletter sign-up