It's not the fall that kills you, it's the sudden stop (Robert's Rule #29)

Years ago...and I suppose I might more precisely say decades ago...I climbed rocks. Granted, they were rocks that were very large and were the sides of a gorge that was hundreds of feet deep, but they were still rocks. Anyway, one of the concerns that people often expressed went something like "aren't you afraid you'll fall" or "you could die in a fall". Being young, and convinced of my immortality because of my youth, I was not concerned about falling...after all, I was careful and, as I often replied, "falling doesn't kill you, it's the sudden stop at the end that kills you". In essence, it isn't a fall that kills you, it's the not falling.

So, how does this apply to technology, or more specifically, to application development? If we rephrase this idea, by replacing "fall" with "fail" (which doesn't really change the meaning - after all, a fall while climbing is a failure - at least to climb), then we can say that it isn't the 'failing' that kills you, it's the 'not failing'.

If it's still not clear, then let's look at a concept from extreme programming (something that was in vogue a few years ago) called "test-driven development". Here's the basic idea: write a test that you know will not pass, write the minimum amount of code that you think will make the test pass, run the test, modify the code and run the test until it passes, refactor the code to make it conform to standards. (You can find a more thorough description of test-driven development at Wikipedia.) Note: I suppose it's a bit of semantic gymnastics, but even though we generally say the test 'fails', our expectation is that the test 'fails' - so what we really mean is that if the test returns a negative result it has succeeded.

As I've mentioned in previous posts, more code is not the answer, and writing code is similar in many ways to other forms of writing - it should be clear and concise. The easiest way to develop clear and concise code is using test-driven development. Of course this also means that since you develop unit tests at the same time as your code, quality is much easier to ensure - which is important in itself.

Granted, there is much more concerning this topic that we could explore...there are rabbit holes to go into all over this landscape, and I would encourage you to follow one or two of those to see where they lead. As a practical matter, however, I am solidly behind test-driven development and have combined two widely accepted engines to facilitate test-driven development for web developers writing JavaScript. This tool (called GARDA) is free to use, and will soon be available for download so you can run it locally. So, use test-driven development to climb to the heights of your ability, remembering "don't fight stupid, make more awesome".