Last summer, my father-in-law purchased a really nice John Deere riding mower. The mower was amazing.  It did everything a mower was supposed to do, and a lot of what a tractor could do, as John Deere designed it. But within days of getting it home, my father-in-law (Jay) began drilling holes in the hood of the mower, over the wheel wells, and on the trailer he purchased. I know Jay well enough now, so none of this was a surprise to me. He has modified most of his tools, and he considers everything he buys (vehicles, mowers, screw drivers, etc…) simply a tool. Most of the time, he already has a plan for modifying the tool before he leaves the store.Jay buys the best fit for him, filling most of his needs with an off the shelf product, and understanding what needs to be modified to meet his specific needs. I’ve always wondered why most people don’t think the way Jay does when it comes to software.

People tend to expect a piece of software to be the “be all, end all” or “one size fits all” application. Developers and users alike, find themselves in these never-ending, “I’m a Mac. I’m a PC” or “Java vs. .Net” or “thick client vs. thin client” battles all because they want to believe in their heart of hearts their chosen product is infallible, and or at least a much better pick than the other person’s choice. Yet, nothing out of the box does everything, and no off the shelf product applies to everyone.

In fact, by the time a product has attempted to solve every combination of needs imaginable, it is too bloated or complex to work with properly. Users, over time and versions, either suffer along with the product or switch to other faster and easier to use products, repeating the cycle all over again.

So I offer these challenges to ponder…

Customers, when the time comes to purchase software, will someone convince you the “latest and greatest” product “slices, dices, chops, and purees” when you only need a slicer, or are you going to use Jay’s example? Will you prioritize all of your needs first; find the product that best meets high priority needs; then look at how easily the product can be modified to meet the more specific needs?

Software developers, are you going to account for an infinite combination of user needs until your product is too complex to use or support, or are you going to build an application to perform your determined task better than anyone else? Are you going to be open in your design enough for the Jays of this world to easily configure or customize your application to meet needs you may have never considered?

By the time Jay had finished his modifications, the mower had clamps to hold all of his basic tools, and the trailer had been “bumped out” to fit wider loads, and eye hooks were added allowing him to bungee cord down what was in the trailer. Even the “lawsuit avoiding” safety features, as he saw it, had been by-passed, because he really wanted to mow grass in reverse, without holding down a little yellow button. This summer he is enjoying a mower that fills his needs, and his yard is nicer for it.