Most modern web applications are nothing more than a bunch of boxes. One holds a name, another holds the value selected from a list of options, and another indicates that one group of boxes is somehow related to another group of boxes. And just like designing a storage system for your closet or your kitchen, boxes that you thought were going to be important at the outset end up being useless, extraneous, or ignored once the system goes into production.
Such was the situation with this client; they had built a complex web-based product for tracking their data, and a year later, realized that it was too complex. It’s a common problem which I call the “Buffet Paradox”: loading your plate up with every possible item ends up somehow being less palatable than a single, simple steak.
Their initial request was for documentation. To continue the buffet metaphor, they figured that with a canonical list of every possible item, they could sit down at the table and determine which dishes made sense, and which didn’t. But, there were complexities…salad dressing was one “item” with 6 or 7 different possibilities. And croutons straddled the border between the soup and salad area, making an appearance in both.
So I obliged in appropriate fashion by clearly defining their problem and proposing some solutions. No matter what method I used, it was going to be a decent amount of work. First of all, I hadn’t built the initial system, so I would need to spend some time getting up to speed on how things were put together. Then, I could take several paths for the actual physical documentation: first, I could start with the initial design document, updating it to reflect post-launch changes that had been put into place. Or, I could run through the system and take screenshots of the various pages, pasting them into a Word document. Or, I could pull up the screens, copy the fields into Excel, do some formatting and rearranging, then paste a table into a Word document.
No matter the approach, there would be tradeoffs: updating the design document would be incredibly time-consuming, and the chances that I’d miss a field here or there were high. Screenshots would be likely to cover all the screens, but were not editable, and wouldn’t show things like picklist values or which fields were actually just references to data entered elsewhere. Pasting a table was a reasonable compromise, but still wouldn’t capture every piece of data, and wouldn’t reflect the actual look and feel of the page, which might cause some confusion.
So, I presented the options to the client. And, to my pleasant surprise, the client came up with the optimal solution on their own: instead of asking for a detailed list of the items on their “buffet”, they would just go up to the buffet with a pad of paper and write down the items to remove. In other words, instead of developing a reasonable facsimile of their application, they’d simply display the actual application on a projector screen, go through it page by page, and write down the things to change.
Of course, that was the best solution from the get-go, but it wasn’t necessarily one that would have resonated with the client. It was a solution that shifted the burden of work to their side of the table.
I think that this case produces three key lessons learned:
First, of course, is to avoid the “Buffet Paradox” in the first place. Start small, iterate frequently, and add additional fields, functions, screens or even menu dishes over time as you understand more about what’s needed and what’s popular.
Second, realize the shortcomings of copies. The “sandbox” version of an application might not have all the same data or users or even bugs as the production version. It’s not always practical–or even advised!–to do the actual work on the “live” application, but know that, just like when you copy a CD track to an MP3, some fidelity is lost in translation. Just like a mechanic can’t diagnose your car by describing the problem over the phone, the best way to analyze an application is to look at the real thing.
Finally, understand that the “optimal” solution may not be the one the client wants to implement. Sometimes consulting involves just being a sounding board; take the input, define the problem, delineate some solutions, and, like an episode of CSI, let the evidence speak for itself! If the solutions you propose are all more work/time/money than the unspoken “simple” solution, it becomes much easier to say, “But if these seem to be out of scope, we could always do X, which would fix the problem the most quickly even though you’d be taking up more of the effort.”
A blank sheet of paper is a scary thing to behold. Once you’ve put up some options, finding the best one gets that much easier.
