Most stories about zen masters, gurus, or other paragons of wisdom follow a similar pattern. The pupil discovers a problem. He or she struggles with it. The problem gets more and more overwhelming. Solutions are elusive. Finally the pupil goes to the master and pours out his heart, whereupon the master offers a pearl of insight that radically reinterprets the problem.
There’s a reason why this narrative exists in every culture: human beings need the insight that comes from synthesis, pared down to its essence. We crave the simple but profound:
- Less is more.
- Do unto others as you’d have others do unto you.
- A watched pot never boils.
- Freedom isn’t free.
The software industry desperately needs this sort of insight, but far too often I see us operate in the stage of the narrative where the pupil misunderstands the problem, struggles, and makes things worse. This is true of all sorts of software–even mobile apps and consumer web sites–but I’m especially thinking about enterprise stacks. The architectures that I encounter today are significantly more complex than the ones I drew on whiteboards a decade ago. Applications used to consist of a binary and a handful of config files. Now they consist of hundreds or thousands of artifacts: executables, shared libraries, plugins, parsers, databases, triggers, stored procedures, data sets, documentation, brandable CSS, image libraries, drivers, rule sets, comm channels… Products have more features–way more. We sneer at offerings that aren’t solutions. We build federated, distributed, loosely coupled fabrics that run in sophisticated clouds and that abstract physical geography, hardware, network interconnects.
We aren’t as troubled by this complexity as we should be. All those features we’re building into a product? And all the planning that built those features? They’re symptoms of a problem, not solutions. Nobody really wants a shopping cart framework with 10,000 configuration options; they want to sell in a way that delights and engages customers. (Okay, I guess some software really does make people happy with greater complexity. Photoshop has 10,000 menu items, and its power users love it. Perhaps this is because it enables enables human creativity and passion, and creativity thrives on possibilities. I don’t think most software is like this…)
We imagine we’re going to outrun all this complexity with kaizen. We’ll get smarter, adhere more to agile methods, use more efficient tools, double down on use cases, or implement some other technique du jour. And we’re not crazy–there are gains to be had, and they’re important. Continuous integration kicks out dozens of builds per hour. Product management teams accomplish feats of planning, coordination, and analysis that would have caused jaws to drop a few years back. Test automation is light years ahead of where it was when I first did a handoff with a tester. The amount of data that we index, transform, and marshal to achieve business purposes grows at an astonishing rate.
But in the zen master stories, the pupil never wins through sheer grit.
On my work blog at Adaptive Computing, I posted an article about how I think the entire cloud computing community misunderstands the true emotional motivation of its customers. IT folks who buy cloud management software may say that they want “cost savings” and “increased agility”–and I think that’s accurate–but they also want simplicity. They want it in the worst way, even if they don’t articulate that desire, don’t measure it, and don’t use it to justify purchase decisions.
IT is drowning in complexity.
If you want to be a zen master, don’t give them 20 more menu items in the next release. Give them a release where 20 menu items become unnecessary.
For a week, spend 2 minutes per day imagining ways to simplify. Incremental improvements are good, but also push yourself to think more radically. Could you deliver your product in a new way that totally obviates the need for an install, instead of just making the install easier? Instead of making two components talk more robustly through web services, could you collapse a process boundary altogether? Instead of integrating with a third-party app, could you throw away 1/3 of your product and simply use that app to get the job done?
I will be blogging more about how to simplify in coming weeks, and would be very interested in your thoughts on this topic. Please comment.
- Why Scrum Won (java.dzone.com)
- A tale of a 7 year journey in developing software for the enterprise (theenterprisearchitect.eu)
- IBM Simplifies Big Data, Cloud Computing (hispanicbusiness.com)