Anyone can break a shovel...

I was about 12 and my grandparents' turn of the century farm house had shifted on its wooden beam foundation. The whole family was involved in the process of digging up the ends of the beams, jacking them up and laying concrete beneath them to relevel the house. Over lunch, while everyone else went inside, I stayed and continued to dig. The ground in Northern Michigan can be very rocky and at one point I struck a large stone. After about 20 minutes of excavating the stone, I thought it was ready so I wedged the shovel in on one side and attempted to pop it out. Turns out, I had only excavated the top 30% of the stone. With all my weight on the shovel, the handle promptly splintered.


I waltzed into the house proudly displaying the broken shovel as proof of how hard I was working. My grandpa looked at the shovel, scowled and yelled "Hell boy, ANYONE can break a shovel!" I was crestfallen. The proof of my hard work turned out to be nothing more than a measure of how little I knew about using my tools.


Jump forward 25 years and I find the lesson still applies. I am always impressed at how easily some developers and managers in the software provisioning industry are always trying to:

1. Use a piece of technology to solve a problem in direct conflict with that technology's expressed purpose.


2. Decide not to use a technology that is specifically designed to solve a problem because it was 'not invented here' or because it would mean learning something new.

As software developers, it is our job to enhance the state of the art in what we build. We must know enough about the problem and our tools to know what is possible, what isn't and where the lines become fuzzy. For example, a developer who will not use generic collections but insists on manually boxing and unboxing collection contents has not learned the capability of his tool set. Similarly, a developer who insists that databases are 'too much overhead' and decides to wrap a complete custom transactional solution around XML files has gone around the bend only to find an unfortunate and painful hole in his own foot. (The second example is anecdotal!)

We must, as an industry, overcome the stigma of budget and schedule overruns resulting in unusable software. To do that, we must first consider what kind of tool will best suit the job at hand and then strive to use that tool appropriately. If your software is needlessly complex and unmaintainable, it may be that you've done nothing more than break your shovel.