skizz.biz

“Make it look like Excel” is one of those “requirements” that wakes me up screaming in the middle of the night, in cold sweats and gibbering…

IMHO it is almost always a failure of analysis, a failure to dig deeper and discover the actual problem, a failure to “Ask why? five times” [1]

Here’s an example of what I mean, based on a real example that I have seen.

Maintaining Employee Information

Suppose I have an application for the maintenance of employee and employment information. There is a dialog that shows the employment history of the person in a grid that looks something like this:

This grid is editable. Basically they are directly editing the underlying database table.

Why?

Because we need to be able to change the dates.

Why?

So we can enter a termination date and the reason for the termination

Why?

So we can update the employment history when we terminate an employee.

Terminating an Employee

It turns out that when they terminate an employee, they go to the employee status screen, and change the status from ‘employed’ to ‘terminated’. Then they go to the employment history page and update the employment history with the new end date, and the reason for termination.

Consider the implications:

• It is possible to change the status of the employee to terminated without having that reflected in the employment history
• It is possible to change the employment history to reflect a termination, while the employee status still has them as employed.
• The operation to terminate an employee is not atomic (the status field and history entries are changed independently)
• it is possible to change the dates of an employment in the past - without any thought to the consequences.

Here’s a (hopefully hypothetical) example of the problems this may cause. Alice changes the status of Bob to ‘terminated’ but does not change the employment history. The company decides to pay a bonus based on the time that an employee has been with the company. Bob gets a gold watch in the mail despite the fact that he has been working for another company for 5 years now.

Usability Problems

Chris is new to using the system. Diana has just been re-employed by the company. So Chris goes to the employment history which looks like this:

and changes it to reflect the fact that she has been re-employed:

Diana is *really* annoyed when she doesn’t get the gold watch in the mail despite having worked for the company for over 25 years.

Complex Business Rules

Imagine the business rules that would be needed around this implementation if you want to make it reliable and keep it as is:

• you should only be able to edit the last EndDate of an employee’s history
• if you enter an end date you need to enter a termination date
• the end date must be after the start date
• the start date must be after the previous end date
• you can only enter the end date if the status of the employee is ‘terminated’ (but i want to change the history before the end date is entered!)

Complex Requirements

Suppose someone notices that the status and the history can be out of sync - they come up with a couple of new requirements:

• as a user, I want the status of an employee to change to terminated when I change the end date of an employee on the history page so that the status is in sync with the history
• as a user, I want the status of an employee to change to terminated when I change the end date of an employee on the history page so that the status is in sync with the history

Not only are these business rules and requirements complex and hard to understand, they describe the system in terms of the implementation. Since the implementation (the editable grid) is directly tied to the database, you might as well describe the system in terms of changing rows in the database. There is no relationship of the requirements to the actual tasks being performed by the user (Terminate, Re-employ etc.)

Hopefully you see the problem.

Asking “Why?”

So what can we do?

If the original team had asked “Why?” a few more times then the stories might have looked like this:

• As maintainer of the company employment records, I want to be able to terminate an employee, as of a certain date, with a reason so that we can stop paying them a paycheck.
• As maintainer of the company employment records, I want to be able to re-employ a previous employee, as of a certain date so that we have a single record for that employee.

How would that be implemented? Maybe a “Terminate” button on the employee record screen, that pops up a dialog like this:

Simple. Usable. Atomic. Safe. Easy to implement.

So if you find yourself implementing an editable grid, I would strongly Strongly *STRONGLY* urge you to go back to your customer and ask “Why?” 5 more times.

Caveat: Sometimes, just sometimes, it may make sense to have an editable grid that ‘works like excel’. If so, use Excel. That is what it is for.

[1] “Ask why five times” is one of those many things that has entered the lexicon from Taichi Ohno, lean manufacturing and the Toyota production system.
http://www.toyota.co.jp/en/vision/traditions/mar_apr_06.html

This entry was posted on Friday, February 23rd, 2007 at 10:42 pm and is filed under development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.