Kudos to Roger Sessions, the CTO of ObjectWatch. Recently, Sessions took a stand supporting “the intentional architectural design of simplicity into a software application,” which he dubbed “simplility.”
But while I applaud Sessions for championing the case for simplicity in software architectural design, I’m not sure we need a new word for it.
In coining “simplility,” Sessions reasons that we a need a new word because “simplicity” no longer works. He says people take “simplicity” too much for granted.
In a complex, confusing, cacophonous world, people beg for simplicity. We desire simplicity so dearly that we’ve demanded it in a widely used acronym: K.I.S.S. – “keep it short and simple” (or for those more indignant about it, “keep it simple, stupid”).
Think about elements of our culture that crave simplicity. There’s a magazine called Real Simple that covers nothing but how to take complexity out of people’s day-to-day lives. People challenge themselves to live with as few possessions as possible. And if you Google “minimalist living,” you come up with more than 600,000 results not to mention pages upon pages of blogs dedicated to the topic. Heck, Google, Bing, Yahoo and all the other search engines out there exist for one purpose – because we want a simple way to search the Internet.
But how great is our desire to simplify our technology? I’d be willing to bet that if, on its next Patch Tuesday, instead of trying to fix some broken, complex, “cool” function it originally created in haste, Microsoft instead sent an update to its users eliminating the 20 least-often-used functions of Word, Excel, PowerPoint, very few would notice their absence. In fact, if Microsoft were to eliminate these 20 obscure functions – i.e., if Microsoft simplified its applications – many of us might realize a pleasant uptick in performance.
Simplicity deserves a place in the software industry lexicon next to a plethora of positive “-bilities” including scalability, flexibility and, most importantly, reliability. Many developers would do themselves a favor by thinking about simplicity when creating software.
Simplicity benefits the developer. Simplicity avoids complex software management systems. Simplicity allows the developer to complete projects more quickly. Simplicity means reduced errors. Simplicity means faster time-to-revenue.
When developing a new application, operating system or even new functionality, many view speed to market as valuable as -- or even more valuable than -- the actual feature set being rolled out. The reasoning for this is that features are easy to duplicate, but being first to market is impossible to duplicate.
Unfortunately, speed can actually complicate rather than simplify. As Mark Twain once quipped, “I didn't have time to write a short letter, so I wrote a long one instead.” Pressed for time in the rush to be first to market, developers are apt to overwrite when creating features. Moreover, they press to add new features to their programs thinking they will be “nice to have” or “add value” when, in actuality, these features are likely among those 20 I mentioned above that no one would miss.
Desperately Seeking Simplicity
So what can be done to simplify application development? First, complying with existing software quality standards contributes to simplicity. After all, there are reasons why certain procedures, methods and environments become standards – because they are repeatable, successful and widely used. This is why people also often refer to “the standards” as “the basics.” Standards offer guidance and guidance simplifies things…and when this guidance isn’t enough to simplify, there is usually a professional community which, because these things are common and standard, has “been there, done that” and is available to assist with questions and problems.
The other thing to do to achieve simplicity is to use the tools that modern technology provides. So, when assessing application software for structural quality, developers should employ automated analysis and measurement rather than trying to manually assess their work. Manual assessment is grossly inefficient and extremely costly in terms of the time it takes to get even a fraction of the result automated analysis provides.
And this assessment needs to be done throughout the build or customization process rather than waiting for a completed product. Each stage of development in which an error goes undetected makes it 10 times more expensive and time consuming to fix. Automated static analysis provides the kind of simple diligence that can actually generate a faster time-to-market for the final product.
Simplicity not only yields benefits during the development process and facilitates speed to market, but also results in applications that score high in software quality health factors – transferability, changeability, robustness and performance – and that means lower technical debt.
That’s why developers who embrace K.I.S.S. certainly deserve a hug…or at least a handshake.