Agile Methods

Choose the Right Tool for the job

Over the years, I've worked with a number of systems which aggregate data in some way. These have included simple RSS aggregators, the importation of multiple XML formats, and even interacting with a multiple of bug tracking systems. Regardless of the domain, there is a simple concept here: There are a particular set of actions we wish to perform on the data, but quite often the data sources have a variety of data structures.

For some reason, most people immediately jump to the "simple" solution of building a inheritance heirarchy, each with a distinct class/structure beneath it to a specific data structure. This can work fine for quite a few situations and ends up being quite elegant in patterns such as the Data Access Object and others where you can completely encapsulate the data structure and simply forget about it. Unfortunately, this doesn't work in all scenarios.

For example, I'm involved in a large scale Java system where we are retriving XML data structures from a series of different sources (think aggregation). When we started there were twelve different sources in two different formats and the solution looked simple, we would simply import each of the structures and be done with it.

Since I've been bitten by this before, I proposed a different solution. Instead of doing the import in a single step, we would use a Two-Step Pattern to first convert each data structure into our custom structure and simply import that. We've been able to implement this by building a single importer class and creating a new XML-to-XML XSL transform for each new data source.

Just in time too, within 2 months, we were up to 7 different formats from 237 different sources...

Pave the cowpath

At my alma mater, Ball State University, there is a dirt walkway affectionately known as the cowpath. It is a makeshift shortcut from one of the dorms (er, residence halls) to classrooms on the other end of campus. It emerged out of need and student's tendency to take the shortest line between two points. The cowpath has existed for decades, and unless something has changed in the last five years, it remains a dirt trodden path.

What does any of this have to do with producing and managing software? Put simply, when we observe people wearing a path that we didn't anticipate, like when they use our software in interesting or peculiar ways, we have a few options:

  1. Slap the user's wrist and tell him not to mickey with the software
  2. Analyze if the software's user interface created some confusion
  3. Observe the user closely to understand his motivation

If you do #2 and #3 you will most likely choose to pave the cowpath instead of discouraging the user from doing what he wants to do. While I wouldn't advise retrofitting a spreadsheet into a flight simulator, developers and project managers should keep an open mind about creative ways that people repurpose software. A practical example is the Friendster software product. From presentation notes given by Danah Boyd to the Supernova Conference:

What was successful about Friendster had nothing to do with its original purpose or design [dating]. Instead, users saw it as a flexible artifact that they could repurpose to reflect their social practices. As i learned how people embedded Friendster into their daily lives, i was fascinated by how it manifested itself as so many different tools to so many different people. Some saw it as an information gathering tool, allowing them to learn about friends and strangers. Others saw it as a performance tool and a venting site. It was also used as a gaming device, a distribution channel for the drug dealer, an anti-depressant for the voyeur, a popularity contest. Many also saw it as a cultural artifact necessary for all water cooler discussions.

At first Friendster resisted the use cases they didn't ordain, but gradually they saw value in what their user base wanted from the service. They were fortunate to have a flexible system, which helps. They revised their software in minor ways (pave the cowpath), but mostly they just needed to get out of the way.

The next time your users surprise you with the way they (mis) use your software, consider if the possibility that the user knows something you don't. As a consequence you may tap into new markets for your software, and at the very least, by adapting your software to the needs of the user you will make their experience more pleasant.