The price for “simple”

However, most developers tend to work in a vacuum. Regardless of this ongoing increase in complexity they put it on themselves to produce the same "all I want to do is" solution with the same limited resources. The individual developer is no different than the average software user/consumer – no surprise since we’re constantly using software tools created by others so that we can develop new tools for our users – and developers also have the "all I want to do is" mentality. We expect our tools to be simple. To appeal to this, ever since I’ve been coding since the late 1970’s, every tool has advertised doing more with less and in less time.

The reality is that keeping the product simple for the consumer absolutely requires more from the provider. These days we often need many developers with specific skills to produce what appears to be easy for the consumer. Even small companies with a staff of developers have a hard time producing quality software given the volume of options and technologies, ongoing changes in standards and tools, and constant requirement for education to keep up on the latest bugs, patches, and new releases and features.

The price for "simple" increases dramatically as we move forward to create products of increasing complexity. To survive in this climate producers themselves need to recognize that simple now isn’t what simple was before. We can’t expect that because we did it all ourselves before, and were able to produce "simple" for our clients using tools that were "simple" for us, that we can always continue to do so. The blacksmith must give way to the auto manufacturer, or retrain to design tires rather than shodding horses. When developers recognize the dynamics at work they should be in a better position to work with it rather than against it.

Developers also need to work out who is going to pay for this increasing cost of simplicity. End-users don’t want to pay more, after all, it’s all so simple, how could it possibly cost anything? Well, if the consumer doesn’t pay for it then the developer does – and that can’t possibly last if the developer hopes to feed himself or his family. So developers need some way to convey costs in an acceptable manner – either by making what they need on volume, or by providing other services to balance out the investment they’ve made in simplicity.

In some ways we need to convey to the consumer that their simplicity comes at a high expense to the developer. The technical world loves to perform magic, hiding all of the details. If consumers don’t see the detail they can’t appreciate the time and understanding it took into making the magic happen. Of course this isn’t magic, it’s techology, but again this is where the software industry has always tried to blur the line to our own detriment – now software consumers expect everything to be simple, because we’ve created that expectation. We can open the hood/bonnet of the car to expose the engine – the average consumer won’t understand what they see but they’ll appreciate that something significant went into allowing them to just hop in and go. Auto manufacturers don’t attempt to tell their consumers that the product is simple, only that using it is simple, and for that simplicity of use and understanding of underlying complexity the consumer is quite willing to pay significantly for the purchase. Isn’t it surprising that people will pay $15,000 to $50,000 for a vehicle, and maybe get two or more vehicles for a household, and yet they only want to pay $29.95 for software and they insist on free lifetime upgrades for every platform they choose to use? Of course the analogy here is unbalanced but so is the user perspective of what goes into their vehicle vs what goes into their software.

So how do developers cope with these concepts? Change is the constant and adaptation to change allows us to survive in both the business world and the animal world. It’s funny how these basic principles seem to be forgotten from one generation to the next. Is it any wonder that life forms evolve with increasing complexity? Viruses mutate to evade antigens that can kill them – and those that don’t mutate die. Animals that don’t learn to run faster are killed by those who can catch them. Micro-organisms, larger animals (humans included), and everything in between generally learn that working together (or at least in packs) tends to increase chances for survival. I’m not suggesting you rush out to hire help or join a developer commune (is there such a thing? maybe that’s what multi-developer open source projects are all about… never mind…) I’m suggesting that everyone who develops software should understand that as complexity increases we can’t continue to keep it simple unless we learn to deal with all of the factors that make it not so simple anymore. The need for collaboration becomes more evident in order to benefit with and from those who posess complimentary skills – all of us in the same position really. We need to appreciate the compexity involved in making things simple for us as developers and get our users to appreciate the complexity we build into making their solutions simple as well. We need to somehow pay for the benefits we derive from simplicty, and somehow pass these costs on to an understanding consumer. If we don’t we can’t survive in this ever changing market.

It’s interesting how KISS (Keep it Simple, Stupid!) can be warped into Adapt or Die.

Leave a Reply