Friday, November 9, 2007

Solving Software Tasks (Or, How To Install Booster Seats)

It is only by attempting a task in the first instance that we can learn what is truly required to complete it.

My preferred approach in such a situation, one where both skill and knowledge are required, is to begin by attempting to complete the task without reading the instructions.

At first glance this might appear foolish, but experience has taught me that the instructions tend to mean very little until I have some context to place them in.
A series of pictures has no semantic content if I go straight to that, in order to understand the pictures I first need to...for want of a better phrase...play with the pieces.
In the case of the booster seats this means picking one up, glancing at it, dropping it into the back seat and attempting to arrange the seatbelt around it in the most obvious way possible.
Having done this, I quickly decided that my naive attempt was unsuccessful...there was clearly too much slack and movement in the seat for it to be safe.
For my second attempt I took a more thoughtful approach and tried to thread the seatbelt through some provided handles at the back...again, once completed, it was painfully obvious that the seat was too loosely held to be safe.
Having decided this I could now go back to the instructions and reread them...this time things have changed however, this time I have some idea of the problems that the instructions are attempting to solve and a decent grasp of the tools that are available and the different ways they can be used together.
This time, I have experience.
Things were easier years ago when most men, as most men should, tended to be both more confident and more skilled with their hands, they could casually throw together a wooden deck, or tell at a glance the best technique for installing wall fittings and roof mounted television aerials.

Why am I unable to 'grok' the instructions before I have explored the context they are based on?

The stereotypical tendency of men to disregard instructions early on in the process is not, as is usually claimed, because their ego requires them to do so. It is because the instructions themselves carry very little semantic content until their context has been explored and understood.
The time spent exploring and understanding the context by 'playing with the pieces' is not a waste, it is a necessary step to ensure that the instructions themselves are not merely followed, but are fully understood and that when I do come to follow them, I can do so with a deeper understanding of the parts involved and their relative strengths and abilities.

For me this process maps directly to software development, I am a firm believer in designing by doing. The actual ability of libraries, frameworks and other third party code to solve the problems you want solved is an unproven quality until it has been done, and if the third party code is going to fail it is important that this fact be discovered as early as possible in the design process.
The same can be said of the design itself, until it has been brought together.

No comments: