What's in Your Blog Reader?

One of my favorite things about the Internet is how so many random pieces of information can converge upon my life. My web browser is the window through which I view most information that comes my way. I’d like to share with you a couple of interesting people who have found their way into my news reader in the last year.

First up is Alan Cooper, whose company has a blog, but it was their book that was brought to my attention by an article in my news feed. Cooper wrote The Inmates are running the Asylum and one of his key points, nay his mantra, is to always remember that the end user is not like me. Each of us have a key set of assumptions and filters through which we view our world and those assumptions and filters are not likely to be the same set used by our stakeholders.

Think about it… if I said to you that I want a sandwich for lunch, what exactly would that mean? If we know each other well, you would likely guess the fast food joint and possibly even the meal I would purchase on any regular day. But what about on those ‘non-regular’ days when instead of a hot pizza sub, I want a club sandwich at a sit-down restaurant? Even my best friend would have a hard time guessing where and what I want to eat, given all the possible meanings to my stated desire of a 'sandwich’.

The same principle applies to business analysts and our customers. We all have been told at one time or another that our end users don’t actually know what they want, but its the job of a BA to 'elicit’ or 'draw out’ their true needs. We spend our time trying to dig down to the root of a problem, then help the stakeholder either find a process change or the development team a system change to address the need. Sometimes our customers have easily defined problems (“When I click this button I get an error”) but sometimes the issue is not so clearly defined (“I need to know more about my customers”). If the BA uses only their own filters to tackle the problem then the answer will be very unlikely to resolve the customer’s actual problem.

It all comes down to finding the right perspective or lens through which we can view the problem. I remember my very first project as a BA, being brought in at the very end of the project to write process documentation and training material for the business unit in which I had spent the last three years as an employee. My first thoughts when seeing the new application almost ready for implementation were, “This system is so bad my friends are going to hate me when I demo it for them.” Even though there were people who had spent years on that project, who had also previously spent years in the business units, they had used the mental filter of a pre-selected software package to view the problems found in the business area.

While many people recognized that the proposed application had issues, no one was willing to put a stop to the project even though it would have been detrimental to the business area to switch them to the new program. I breathed such a sigh of relief when the project was eventually canceled, knowing I would never have to stand in front of my colleagues and present a 'solution’ that was a bigger mess than their problems. Had someone taken a look at the problems of the business area prior to selecting a vastly inferior software solution, the company might not have wasted so much time and effort on a project that was doomed to fail.

My second insight comes from Jeff Atwood, who runs codinghorror.com, and is about the concept of system optimization. Being a programmer, Atwood has a passion for producing well-formed, elegant code. Being a programmer who understands and tries desperately to meet his customer’s needs, he understands that having the most efficient and maintainable code does not equate to having the most effective product for his customer.

One of the things I appreciate most about Atwood is his ability to see more than just programming standards and guidelines, but to see how the use of those tools can improve the applications he creates for his customers to use.

One of the traps that I find good developers often fall into is not seeing the difference between well written code and code that meets the customer’s needs. Having code that executes flawlessly, that crunches numbers in record time and does all this in a way which can be easily maintained by any novice developer is a good thing, but if the software does not help the end user reach their goals, the application is still a failure.

I remember one conversation with a developer who deviated from the design document to make what he thought was a trivial change, all in the name of system efficiency. It sounded good on paper as he’d save a few processing cycles and the end user would not notice any difference when using the application. The developer neglected to realize two very important facts about the repercussions of making that change. First, while his change improved the code efficiency, it did so needlessly.

We’re talking microseconds saved on a transaction that already took less than a second to process.

This transaction only occurred a few times per month and was performed on a server whose average load was around 10% and whose maximum load was 50%. In other words, the developer spent more time redesigning something that would have worked just fine as designed than would ever be saved by making the change.

Even then, the change wouldn’t have been a big deal, until you realize that if the functionality in question ever had a problem, the support team would now have considerable difficulty in trying to get the user up and running as quickly as possible.

The new implementation was technically correct, but prone to misdiagnosis by the helpdesk. Sure, training could possibly help, but remember how rare the transaction occurs and then remember the turnover rate for a support team and you’ll realize that whenever this function does receive a call, no one who takes the call will likely have been trained on how to handle this one-off situation.

When the helpdesk tries to resolve the issue as they would any other similar problem, the steps they would take that would have fixed the problem under the original design now will not work. Not only did the developer not add value with their change, as there was no perceivable benefit to the user, they actually introduced additional support costs, all in the name of code efficiency.

So what is in your news feed? What articles have you run across in recent times that may not be directly related to your job, but that gave you thought on how you might improve as a BA?