17 of 26

One of the major challenges with doing software development is that you need to be constantly evaluating the direction that you’re heading in with both the code and the end product.  You can’t just decide to do something and then put your head down and do it.  The landscape changes as you develop a product – you learn better ways to do things, roadblocks come up, and your vision of the end product (and code) becomes more refined and  clear.  If you don’t pay attention to these things as you go along then inevitably you’ll wind up miles away from where you should be in the end.

On the other hand, you can’t be changing direction with the wind either.  This is a trap that many programmers fall into.  If you don’t have a solid starting vision for the product or you constantly change the requirements for the product or how it is implemented then you’ll wind up with a big mess or, even worse, the product will never get finished.

The balancing act of changing things that need to be changed and not changing things too often is one of the things that makes software development as much like an art or craft as an engineering or science.  Complicating things further is the fact that what’s best to do for the product often conflicts with what’s easiest to do in the code.

I was working on the eHow Earnings Tracker last night when I had one of those “aha!” moments where I knew that I needed to change the direction I was heading in.

My original vision for the tracker was that it would automatically detect eHow earnings pages as the user browsed the web.  When an earnings page was detected, the tracker would read the current page of earnings, save them to a file, and compare them to the previous update.  The user would be able to see which articles had increases in earnings from update to update and they would have a history of earnings that could be exported.  This  seemed like it would be fairly straightforward to implement and would be a low friction solution for the user.

As I worked on the code, a number of implementation difficulties arose and it became apparent that there would be some usability issues with the end product.

Implementation difficulties (code):

1. Firefox can have multiple tabs open at once which means that, in theory, multiple earnings pages could be loading at the same time.  Writing code to handle this sort of scenario is very difficult in a Javascript based environment.
2. Due to the fact that the code is only parsing one page of articles at a time and the article order is not guaranteed, the code can’t just blindly read & write the entire contents of the current earnings file stored on disk.  Each time an earnings page is viewed, the file needs to be read in and then its data needs to be compared to the current page of earnings to see whether article entries need to be added or modified.
3. The code would be executing every time an earnings page was viewed, even if it didn’t have to.

Usability issues:

1. The user would have to manually click through each page of articles (which can get tedious since articles are only displayed 10 at a time).
2. Since the code was only seeing one page of articles at a time, it would have no way to inform the users of any articles that were added or removed since the last update.

My “aha!” moment was in realizing that the better way to do this would be give the user an “Update Earnings” button that could be activated whenever they were on their earnings page.  That button will trigger the tool to automatically navigate through all of the users’ earnings pages collecting information.  At the end of the process, an HTML page can be displayed showing a summary of all the earnings data.  This fixes all of the implementation and usability issues in one shot.  It’s a rare case where I can simplify the code and improve the product at the same time.