When I was at university I wrote essays. I wanted to be able to write them more quickly so I learned to touch-type, using the awesome ‘type online’ site. My favourite part was the speed test - I found it addictive. My tendency was always to try and go as quickly as I could because that was what I wanted to achieve; but I also wanted 100% accuracy, so I would correct any mistakes I made as I went along.
The good thing about the test is that it gives you a quantification - Your speed was: 80wpm. You made 2 mistakes. I learned through trial and error that my typing speed was higher when I typed slowly. This is because a mistake costs time; the time to type an incorrect letter, the time to recognise the mistake, then the time to go back and correct the mistake. I had confused the effect I wanted (high speed) with its cause (high accuracy). The principle I learned is basically the same one we teach to infants using Aesop’s fable of the ‘tortoise and hare’.
I am now a software developer. As of today’s deployment we have 17309 lines of code: our software is used by thousands of highly trained healthcare professionals to review their competence and plan their future. Meanwhile estimates of the failure rate of major software projects are high. Government IT projects regularly make national headlines for the wrong reasons. This is compounded because compared to other areas of infrastructure engineering, programming is still in its adolescence. Best practices and tools change every few years. And the tragedy of monolothic IT projects is that they usually have the money, skills and man-hours to solve the problem, but the resources are simply not spent effectively. In fact the purpose of the discipline of software project management is to spend these resources correctly.
So it is very important to take the time to build software ‘the right way’. In any line of work there is always pressure to deliver solutions as soon as possible. It can seem embarrassing to explain that a superficially simple outcome will take weeks or months to achieve correctly: the temptation is to be overly optimistic, but that puts you in a situation where you must cut corners in order to meet your deadline.
Building software is not a typing speed and accuracy test - poorly conceptualised code quickly becomes incomprehensible, whether it ‘works’ or not. This is because the number of entities in a piece of code increase, the number of interactions between them increase exponentially. Code must be readable and maintainable and follow industry standards: at SARD we use test-driven development and various other technical and project management techniques to ensure the quality of our code. Even in high-tech, sometimes slow and steady wins.