The blog post “Minimalism — The most undervalued development skill” struck a nerve. You see examples of this all the time in IT. Voluminous documents collecting the requirements and describing the design of some gigantic new system meant to address an important business challenge or opportunity. The solution invariably ends up being 10X the size, complexity, and price of the documents themselves and rarely meets the intended goals. Why?

As the post mentions, there are many intelligent, successful people we can look to who espouse a better solution. Simplicity. A similar, favorite quote comes from Albert Einstein…

“If you can’t explain it simply, you don’t understand it well enough.”

Let’s massage that a little to…if you can’t design it simply, you don’t understand it well enough. That’s especially true in IT projects. Granted, collecting requirements can lead to a huge list of wants and needs. The numbers and types of systems in today’s enterprise, and even small business, environments can be staggering. Those two factors don’t mean that designing, building, and especially supporting huge, complex solutions is a good idea. It isn’t.

While the end result may be grandiose, you can be assured that trying to design, build, test, implement, and support that grandiose vision is most-likely doomed to fail. Before you even get done designing it, the requirements and the underlying business will have changed. Your giant design no longer addresses the need. That’s news that will come as a nasty, expensive surprise to you and your stakeholders when it rears its ugly head in user acceptance testing or some other equally-inconvenient phase of your project.

There is a better way. The “K.I.S.S.” principle…keep it simple, silly. As with tackling any large or otherwise daunting task, e.g. eating an elephant, the best way is to break those requirements down. Take the two or three most valuable (as defined by you and your client/customer working together) and design a solution for those. All the rest of that complexity and expense go into your backlog, to be reassessed and initiated at some point in the future, aka your next iteration, phase, project, or whatever you would like to call it. The benefit being, when you get around to working on the next set of requirements you can discover and address whatever environmental, business, or other changes have occurred since you originally ramped up.

Of course, “real” design here will consider and plan for larger issues beyond your first phase, e.g. scalability, additional features, etc. But, you don’t need to handle every aspect of that right now. Design and build the solution your customer needs today. Get it in their hands as quickly as possible. Then, make adjustments, enhancements, and improvements. The quicker you can turn that challenge or opportunity into value for the client/customer, the quicker you can ramp up the next iteration, and so on.

Meanwhile, that simple solution will continue churning away providing a competitive advantage to your customer and a beneficial, ongoing, business relationship for you.