There are two traps we often fall into when developing something new:
- We try too hard to plan ahead and come up with everything we will possibly need before starting any work.
- We spend a lot of time making one part better and faster when it doesn’t help to make the overall performance better.
In software development the classic problem is one of requirements and specifications.
We usually don’t know what we need to do the first time we approach a problem.
It’s the process of engaging with and solving the problem usually helps clarify thinking – and when we have finished with our first solution we now know what we really need to do to solve the problem.
The idea of right first time simply doesn’t work when we don’t know what the right way is yet.
A better approach is to prototype our way to the right solution.
We ought to start small and simple – designing something we and others can understand.
Whether it’s a business process or a software program, once we can show others a working prototype we will be able to see reactions, get feedback and other useful information which can help us refine our ideas.
It’s also important we don’t get too fancy or try to locally optimise things.
Something very clever right now may be hard to understand in three year’s time by someone else, who might decide to throw out all our work and start again instead.
Local optimisation is the idea that we work very hard on speeding up one part of the process but miss the real bottlenecks in the system.
The overall time any system takes to work will be controlled by its slowest component. Making any other part work faster will not reduce the overall time.
For example, it doesn’t matter how fast we get ready in the mornings if the real bottleneck is how long it takes the bus to get to our stop.
We could be 20 minutes early – but it’s the bus time that will decide whether we are late or on time to work.
Our natural tendency, very often, is to try and do more – plan more, think more and have more.
In reality that leads to bloat – creating large unwieldy systems no one loves.
We would be better off following a few simple rules:
- Prototype then polish. Get it working first, then try and make it better.
- Doing nothing can be very constructive. Words that aren’t there can’t be read wrong. Code that isn’t written can’t fail.
If we must do something – then we should concentrate our time on the things that deliver exponential results, not incremental improvements.