Sealed with a K.I.S.S.: Keeping IT Software Simple


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.

I disagree.

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.

Simply Software

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.

Filed in:
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Jonathan Bloom
Jonathan Bloom Technology Writer & Consultant
Jonathan Bloom has been a technology writer and consultant for over 20 years. During his career, Jon has written thousands of journal and magazine articles, blogs and other materials addressing various topics within the IT sector, including software development, enterprise software, mobile, database, security, BI, SaaS/cloud, Health Care IT and Sustainable Technology.
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item