Value in simplicity
In looking through my Twitter stream the other day I came upon an interesting tweet from Andrew McAfee pointing to an article in Wired titled The Good Enough Revolution: When Cheap and Simple Is Just Fine. It's an extremely insightful read, especially in light of the work I referenced in my recent posts around finding solutions to user problems. If I could sum up the article into a key takeaway it has to be the paragraph below:
The world has sped up, become more connected and a whole lot busier. As a result, what consumers want from the products and services they buy is fundamentally changing. We now favor flexibility over high fidelity, convenience over features, quick and dirty over slow and polished. Having it here and now is more important than having it perfect. These changes run so deep and wide, they're actually altering what we mean when we describe a product as "high-quality."
I believe this concept applies to enterprise IT products and projects as much as it applies to consumer products. IT projects can no longer be mega-projects that deliver overly complicated solutions that attempt to solve every conceivable problem, real or perceived. Instead we need to be quick to market and deliver focused solutions that solve a small number of the right problems. What I think is also important to note is the interpretation of "quick and dirty" and what is meant by "having it here and now is more important than having it perfect". To me, in the context of this article and enterprise IT, "quick and dirty" means a short time to market and delivering the simplest possible solution that solves the right problem, or at least the most important 80% of the right problem. Quick and dirty does not mean cutting corners or sacrificing technical quality (e.g, bugs, poor performance, poor code quality, etc.) to get products out the door. Similarly having it here and now rather than having it perfect does not refer to a lack technical quality but to the need for quick delivery of a product that targets a single or small number of the key problems in an extremely easy to use manner and does nothing more.
I recommend reading through the whole article and also Andrew's blog post on the same topic.
For me, these articles re-enforce the notion that we need to truly understand how our users work and the issues they face in day to day work so that we can solve the right problems and understand what quick and simple solutions could be.
Labels: application development, solution design