Wednesday, October 24, 2012

The Art in Empathy

The continual empathy of your clients is a key component of analysis. A separate entity from your sponsor, the clients are the people who will directly wield your software. Sometimes these folks overlap with the people who paid for the development and sometimes they don’t. Regardless you would do well to heed your clients’ desires as in the long run the clients keep you employed, rather than your sponsor.

This may strike a slightly odd chord, but it is akin to pointing out that you are more accountable for keeping your car running than the bank that lent you the money. All the bank cares about is that their loan is paid back with interest. But you will be the person driving your car and how you care for it and drive it determines how long the car will last. Similarly how well your project meets the needs of your clients will determine how long your software stays useful, even though your sponsor is providing the financing.

Amazingly enough the client enjoys relating their desires to someone who expresses a genuine interest in their needs and their working environment. You should try to discover what keeps the client awake at night: what are his worries. Nothing pleases a client like a designer who knows his workday life in detail, his daily routines, and what he faces in the way of competition and challenges in his office.

Analyze the big picture, not just the snapshot relevant to what you perceive as the scope of your project. Anticipate what the client wants: don’t wait for them to ask. Finally in those instances where you’ve identified a can of worms without a ready solution, consider what alternatives are available to monitor, mitigate, or manage the issue.

Interviewing for requirements seems simple enough, yet actually listening to a client discuss his desires takes a considerable amount of insight. You need to understand the sociology of his office and the things he wishes he had but doesn’t know how to ask for. Many times an employee is shy to relate his frustrations after finding that doing so in the past only set him apart as a complainer. You need to commiserate with him (without being smarmy or condescending) and then step back and independently think of ways to improve his working life.

Design extends beyond its up-front activity: once you’ve installed the initial version of your software you need to revisit the client to assess the full impact of your creation on his daily activities. The artistic thing to do is to create a system that your client appreciates long after you are gone. Continued empathy is the key for doing so.

Tuesday, October 9, 2012

Artful Stress

How much can you pump into that water balloon before it pops? Wouldn’t you like to know this before you get into the water balloon fight? Stress testing software is both an art and a science. Some of the problems you are trying to ferret out are sublime and intermittent and may depend upon environmental loads that are outside of your direct control. To run a fully representative stress test therefore you may need to wait until your full production environment is up and running.

At the same time though, if you delay this crucial piece of quality control until late in the development cycle then you risk being so locked in to an architecture that you are prevented from making effective changes.

To avoid such lock-in I like running simulated stress tests as early as possible. Once you have the physical database designs and user interface for updating the data, simulate the expected load and see where locks and waits occur. If you rely on outside web services then load them up with a few times your expected average use to see how they respond when under peak loading.

Maybe consider extrapolating from some smaller balloons before you fill up your real soaker, eh? Complicate the process by running large concurrent batch jobs on the same server or run a virus scan, a backup, or a defragmentation utility.

Another effective way to avoid scalability issues is to restrict developers to an undersized server, limited in speed and memory. Be aware however that although this is a fair test of design efficiency it's not really a fair test of deadlock avoidance or failover cascades. Often these have to be directly simulated with deliberately bugged code to make sure a future developer doesn't inadvertently pull the whole system down.

Artfully stress testing your system early will make you sleep stress free once it is in production. And keep you from getting soaked in hot water later.