In his excellent book, Customer Centered Selling, Robert Jolles relays a poem about consequences:
|
FOR WANT OF A NAIL
For want of a nail, a shoe was lost Ben Franklin |
A recent client lacked concern about building software regularly and successfully. In his mind, build failures were equal to the annoyance of a hobbled horse: something resolved easily when a release date approached.
But this same chain of events could be applied to the software business. My crude version of the poem – adopted for software development – lacks the poetic prowess of Mr. Franklin. Hopefully, though, it illustrates a point.
|
FOR WANT OF A BUILD
For want of a build, a test case was not executed |
We would all be well served to remember the potential impact of small problems as we consider where to spend our resources. Little annoyances like failed builds or test cases can be very early indicators that you are “losing the war” in your development efforts.
How important are the little annoyances in your software organization? Do you get concerned if a particular build effort fails? Do you have developer test cases? Are they executed regularly? Who gets heartburn if they fail?

August 8th, 2007 at 10:38 am
The anology is very good, but anyone who has riden much knows that to really not lose the horse you need to get off the horse before he is limping and inspect the hoves to know the nail is lost.
In software this is annologous to using static analysis every time you build to make sure that no horse has any obvious “nails” missing before your code goes into battle (e.g. testing and / or deployment).
Newer static analysis tools (like Sofcheck Inspector, www.sofcheck.com) can do this and don’t suffer from the false positive problem that early tools like FindBugs or PDM do. Try the free version. It might find some missing nails.
Everyone knows you can’t test 100% of your code paths so why not use a tool that will do that before you test which is really to check functionality not correctness.
August 22nd, 2007 at 4:03 am
Squeezed Links: August 2007…
Writing Maintainable Code - Does writing maintainable code mean writing the best code you can or writing code with technology your successors can understand? Good thought stuff by Paul Bourdeaux.
The Worst Type of Project Manager - If you have ever h…