Monday, 6.27pm
Sheffield, U.K.
There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies and the other is to make it so complicated that there are no obvious deficiencies. – Tony Hoare
Too much in life is about compromise.
If you work in a business, for example, do you think you’ll get the best tools and finest training available on the planet to help you do your best work?
That question isn’t worth answering but it is interesting to ask why that doesn’t happen.
Take the practice of programming, for example.
A program, in its most general sense, is a plan, an algorithm, a set of steps which, if followed, reach a specified end.
And a good question to start with in any problem situation is to what end?
What end are we hoping for by following this program.
Perhaps it’s a program to help us lose weight, to become less anxious, to market our company more effectively or get a particular product to market.
Or, of course, it’s a program that does something – a web application, for example or a spreadsheet.
In all these cases what approach is going to help you construct a program that works?
Tony Hoare’s observation in the quote at the start of this piece can also be looked at as a matrix, as in the image above.
Some things are obviously wrong – obviously a bad idea.
Like stepping into a puddle on the road or leaning too far over a deep hole.
A small number of things are obviously right.
Given a set of choices about what to do next one of the options is often a fairly clear next step.
The fifth step or the fiftieth step might be harder but the next action, the next move can sometimes be obvious.
This situation where it’s easier to be certain about the short term and much harder to be certain about the long term means we can make the right decisions for right now – but they are also almost always compromises.
When we work in groups anyway.
That’s why so much business is done using spreadsheets when almost any other alternative would be better.
We use spreadsheets not because they are the best tool but because they meet the requirements for a lowest common denominator.
It allows the largest number of people to collaborate on a project that involves numbers where they can understand and manipulate both the tool and the data it holds.
In many software packages you can manipulate the data but not the software itself.
And, in a sufficiently complex package, your ability to change the data is also limited until eventually you grind to a halt, stuck in the equivalent of a digital swamp.
The approach many people take is to take refuge in complexity – creating more complicated programs that try and address their complicated needs.
The problem with this complexity is that it also makes what’s going on much less obvious.
You don’t know if this particular approach is going to result in your falling off a cliff or making a successful moon shot.
These two extremes – between obvious and not obvious – dominate our thinking and so we go for safe solutions because we don’t want to take the risk of doing something more ambitious.
Unless you’re working on your own, of course.
If you’re doing things your way – ignoring what is happening everywhere else then you have a chance to create something new.
Or fail, of course, but on the whole you’ll learn something whatever happens.
If you want to break through this the challenge is to get the right perspective.
And that really comes down to the number of lines in your program.
As humans we can really only hold five to seven things in working memory and think through whether the way in which they are connected works or not.
If your plan or program is a hundred items long you need to group them and keep grouping them until you can describe them using five to seven lines that cover the major things you’re trying to do.
That’s the point where you can differentiate the wood from the trees – where the big picture emerges from the detail.
Okay – those are cliches but they make a point.
But, if you want to go past the cliches and look at how you might actually do this this article has a go at distilling a long Wikipedia article into its main points and comes up with a model that you can look at for yourself and see if it meets the need to be obviously right or wrong.
I suppose the point is this – thinking in terms of programs is a very powerful approach.
Once you’ve written a program that sets out what you need to do to reach a specific end you can run that program and see what happens.
And you can change it if the results aren’t what you want.
Because the secret to constructing a program that works is not just about making a great design.
It comes from running it, testing it and debugging it.
And if you do that enough times you’ll end up with a program that makes a difference.
Cheers,
Karthik Suresh
Handcrafted insight 