Getting Across The Domain

Before you can work on ComingUpToSpeed or GettingUpToSpeed you have to work on GettingAcrossTheDomain. This is not about fluency or ability, yet; it's about defining scope and gauging the size of a development.

If you're very lucky you can see AllOfEuropeInJustOneWeek. A similar activity, when faced with a new language, is reading the index of the reference manual. This doesn't give you functional knowledge - it gives you only a conception of scope.

But when faced with a new problem domain you don't have the luxury of an index or a packaged tour. There are people to interview, specs to review, and books to read, but relating their information to your brief, and deciding what your brief really ought to be, is not straightforward.

So here are some tricks for GettingAcrossTheDomain:

• Find the guru. In each problem domain, someone knows it, really knows it. Often that someone isn't on site, maybe doesn't work there any more. Or maybe they're off in academe some place. Ask around and see who it is; then figure out how hard it was for them to get where they are, and whether there are shortcuts to their knowledge.

• Ask junior. Management, the guru, and your new colleagues may have a very different view of this thing than the bright young person who wants to get ahead. S/he won't have perspective, but s/he'll have depth, and s/he'll be only too eager to tell you how deep s/he's got. By gauging the quality of junior, you can get a good idea about how much is left unplumbed.

• Count the managers. Generally, the bigger the problem, the less managers want to deal with it. If there are a lot of mucky-mucks all trying to get ownership of a problem, that's because it seems easy. Maybe it is; but then dealing with many managers is hard.

• Spot the totem. Most problems have a physical or biological analog. Try to find it, and then run it past everyone. Your seven blindmen may still be confused, but once you factor out the elephant you'll feel much better. Then refine it. Is it a wooly mammoth or an ElephasFumentii? Is it dead, alive, or, like the heffalump, not quite tangible? And is there just one rogue or a whole herd?

• Find the other side. You have a stack of requirements on your desk in which you could drown. So, break on through ... find out what's not in them. What aren't you building. What's not your business?

• Go deep. It's too easy to use these guidelines; you can miss a lot of very important things. So go limp; don't ask questions, don't worry terminology, don't argue procedure and don't take no for an answer. Let the problem fit itself to you. Let yourself mould to the problem. Don't look for surfaces; don't try to see the thing; try to embrace it. Accept it. Immerse in it and drink it in and lose yourself in it. Don't fight to stay afloat. Drown in it and become a fish.

Others? --PeterMerel