Friday, November 9, 2007

Infinitely Malleable Software (Could it?....yes, it could)

It seems to be almost a dirty secret in software development, it is certainly not something Ive seen discussed much, software is for most intents and purposes, infinitely malleable.

When a client asks 'could we make it do ', the answer, ultimately, is 'yes, we could'.

This is the ultimate problem with software, and I could easily argue that this is one of the main reasons that many software projects fail...the secret to releasing software successfully is choosing very carefully which of the infinite possible features available are right for the specific computer program at hand.
This is the reason that good ideas are easy to think of, but successful and popular implementations of any specific one are much harder to find.

Zawinski’s Law states:

"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."

My argument is, of course, that there is no software solution that cannot, at a pinch, so expand.

This is why it is vitally important that you personally resist the temptation.

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.