Monday, August 3, 2009

To Capacity

Most systems have ideal and maximum operating parameters. Think of things like temperature, size of disk available, number of concurrent users, etc. Whether or not you know them, your system has ranges within which it works quite well and ranges in which it's working but getting strained. Over time, you rewrite things and add features to become more efficient; the system's capacity grows.

People are the same way.

There is a range of things that the average employee can do well. And there is a range of things that they can do but the strain will show. After that, well, you're outside capacity. The trick is finding these ranges, using them, and growing them in a productive way.

For example, I once hired someone right out of college. He had an immense talent for finding weak points in a system, and he was quite good at whipping up scripts and utilities for data generation and the like. He had no capacity for writing up a test plan; he'd think of it and do it, but writing it all down was very hard for him. This was his base capacity.

Asking this person to do things outside his capacity simply doomed him to failure, just like asking a system to work with twice the max concurrent users will fail every time. So I didn't. I asked him to do things within his capacity, and sprinkled that with exercises to stretch his capacity. I asked him to:

Perform exploratory testing on a feature. This had him working within his capacity, a sort of spontaneous interaction with the system, and also helped him learn how to write things down. Sure, it was as he went along, but getting him thinking about expressing his tests in writing is the first step to anticipatory writing.

Create a script that everyone could use to generate data. The scripting he could do in his sleep, but for anyone else to use it, he had to learn to document it. This was teaching him to think of others and of their knowledge levels and how much communication they needed. This one took several tries!

In each case, the important part was to take advantage of what he knew, to make the meat of a task within his capacity. Some aspect, however, was just barely outside what he could do. Because it wasn't the whole task, the frustration levels stayed down. He was able to be a productive member of the team - the exploratory tests and data generation scripts had value - and also to learn so that he could over time become an even more valuable member of the team.