Fail fast, fail cheap!
I was explaining this to some junior programmers the other day and it’s worth repeating. Failure is fine in software engineering, in fact it is expected: I get nervous if something works first time these days as I know my limits and expect to make mistakes. However I think that new programmers don’t always realise that failure is acceptable and in some cases failure is preferred, this is especially true during research and development tasks. Consider the following diagram representing three programmers A, B and C working on a task over a period of time, each arrow represents one attempt at a solution.
Assume the task that has been set is complex and contains some degree of uncertainty which means that the first few attempts will probably fail. Which programmer would you want working on the task? If the task is actually impossible then programmer A will be the cheapest from a business standpoint as they fail earliest followed by programmer B and finally programmer C. Also, programmer A will have five attempts at a solution compared to programmer B’s two and a half attempts and programmer C’s single attempt. As iteration leads to improved quality (Boyd’s Law) this means that programmer A is also likely to hit on a more superior solution than programmer B or programmer C in the same time period.
The interesting thing here is that in my experience new programmers tend to work like programmer C: they will attempt a single solution working diligently to overcome any hurdles they encounter, no matter how severe the hurdle. This sounds harmless but remember that few things are impossible in programming, so the more a programmer hammers away at a problem the more likely they are to fudge a solution and that solution (in my experience) is not often of a high quality. The counter point to this is that more productive programmers will rapidly discard attempts early in each attempt when it becomes clear that the solution though possible is not actually desirable e.g. the dog is hungry and solutions include: A) feed the dog B) kill the dog.
This can also be observed by monitoring how long a programmer will remain stuck for before asking for assistance. The most productive programmers will get help within minutes of becoming completly stuck. However the least productive (and often least experienced) programmers will often struggle with the problem for days before actually asking for assistance and this delay is expensive in terms of money, deadlines and product quality.