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:
- Use a piece of technology to solve a problem in direct conflict with that technology's expressed purpose.
- 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.