Monday, April 22, 2013

Learning from my work notes

As I read through my work notes from last week, I made a few interesting conclusions. As a little background I'm working on integrating a web based system and an access control smartcard system. To bridge the gap between web software and the smartcard reader hardware I'm using an old-style ActiveX component. The component is controlled via Javascript that also communicates with the server.

Week 16 Work Notes

Tuesday Apr 16
  • Testing ajax calls. Adding error handling when json parsing fails, or if there is a server exception, or an Ajax timeout.
  • Starting to work on the "activate card" function in js.
  • Adding a progress indicator to show we're in the middle of a ajax and/or cardreader operation.
  • Thinking through how to handle the removal of a card when we're in the middle of a transaction.
Wednesday Apr 17
  • Refactoring out all ajax calls into its own js-class.
  • Fixing progress indicator (which stackoverflowed in IE8)
  • Learning more about ActiveX exception handling when called from js.

Thursday Apr 18
  • Now catching and handling all js exception with window.onerror.
  • More testing of error and exception handling.
  • Adding error handling for when card is removed during transaction.
  • Testing and fixing validation of input fields.
  • Fixing ajax timeout error handling.
  • Thinking through card validity dates, and when a card is to be considered expired or empty.

Friday Apr 19
  • Formatting of date and time. Trying to replicate what goes on in Java.
  • Coding empty card recognition. Discover that a null end date means the card never expires. Have to change my if statements accordingly.
  • The name field from the card is full of \0000. Clean!
  • Enable/disable code for input fields is all wrong. Refactoring to methods into one that handles all cases.

32 hours

Summed up, I spent 32 hours working on the following:
  • UI: Error handling and input validation (Ajax, ActiveX, card data)
  • UI: Progress indicator
  • UI: Enabling/disabling of input fields depending on state
  • UI: Datetime formatting
  • Business code: Recognizing empty card put onto reader

Conclusion #1

I spent almost all time dealing with user interaction issues. Did I have to spend so much time with error handling and GUI stuff? I guess not. I could have skipped a lot of the error handling code and testing I wrote. I could have skipped the progress indicator. I could have trusted the user not to click buttons at the wrong moments. Basically I could have saved a lot of time.

But I didn't. Why? Because otherwise I would have ended up with a really low quality application. Software quality is all about user experience. This is conclusion #1:
  • You need to pay attention to detail and invest a lot of time into UX if you want to build high quality software that makes users productive (and happy?).

Conclusions #2 and #3

What if I were to estimate the time required for the tasks I completed during those four work days? Well, actually all of the tasks are sub tasks to just one user story:
  •  Activate Card: Make it possible to activate a new card and write name, access list, validity dates and amount to it.
In reality I estimated a bigger load of work that just this story, but what if I had estimated just this one story? How much extra time would I have added for the error handling and ux stuff? Maybe a work day, 8 hours. Why such a discrepancy to the outcome? I think for two reasons, conclusions #2 and #3:
  • No matter how much work experince you have it is just darn difficult to understand how many small tasks are needed to get a story done.
  • Your boss is not going to like it when you add four days to the schedule for just "error handling". And he's going to get the answer he wants.
That's all for now. :-)
Post a Comment

Archive