Maybe better known as “Keep it Simple, Stupid”, the KISS principle is a cornerstone in good design. It fundamentally states that when designing a product, it is critical to keep everything as simple as possible. Simplicity makes it easier for a new user to understand how something works. Simplicity makes it easier for long-term users to do the things they need to do. The KISS principle has been used by many in the field of software design and development. Simplicity is so key to good usability, that people in software design and development often think that the KISS principle originated with user-focused software design. But it didn’t.
The KISS acronym was coined by the Lockheed Skunk Works’ lead aircraft engineer, Kelly Johnson in the 1960’s. While creating aircrafts such as the Lockheed U-2 and SR-71 Blackbird spy planes, the Air Force came to realize that in order to effectively build, repair and maintain these jet aircraft, it was critical that they be built as simply as possible. They knew that every aircraft would have to be built, repaired and maintained by people often in challenging conditions. They knew the key to having a reliable fleet of the largest and most complex aircraft in the world was simplicity. Simplicity was easier to build. Simplicity was easier to maintain. Simplicity was, and still is one of their fundamental design goals.
But My Users Are Smart!
Back in the world of software, the process of creating new or improving existing software often begins in design meetings. In these software design meetings, stakeholders from various parts of the organization come together to define the requirements and needs for the new system. These individuals often start their discussions with the countless needs of the people they are representing. Often, there is a feeling in the air that “the system can be simple as long as it does everything all potential users of the system may want to do.”
This attitude is even more prevalent when designing enterprise software for a specific group of users who may be internal users, or for a captive set of users who have no choice but to use the system. Often, the argument is: “But my users are smart! These are not normal end users. This is our custom enterprise software we are talking about. It is these people’s jobs to learn how to use our software. They don’t need simple, they need complete to do their jobs.”
This type of approach never ends with elegantly simple software.
The Risk of Designing “Bloatware”
Many stakeholders start out with the best intentions and with the goal of designing a simple, easy-to-use system. However, unless stakeholders are willing to make the hard decisions of what NOT to include in their systems, inevitably, bit by bit, feature by feature, the project morphs into a large and difficult to handle system. It may be full of seemingly simple-enough features, but as a whole it’s a monster.
The result is “bloatware” — software that is inefficient due to the accretion of a dizzying array of features that no one is willing to live without.
When asked the question: “Do you really need this feature? It seems to be adding complexity without a huge benefit,” the typical response is “Absolutely. Our users can’t do their jobs without it!”
But there is so much more at stake than just users.
Cost, Time and Quality
The original KISS philosophy had nothing to do with users. They were not focused on people having a simple time riding in the planes. Keeping it simple was about building, deployment and maintenance of their aircraft. It was about reliability. It was about having aircraft that would work in harsh conditions and could be repaired in those same conditions.
In design meetings, participants often get carried away in trying to design a system that will handle every aspect of their business process including outlier situations, and request every feature they can imagine. But in doing so they are adding huge costs and enormous risk to the project.
The main critical success factors influencing project success are cost, time and quality. When feature upon feature is added to any system, the system bloats to a size that becomes very difficult to build and maintain. If design contributors are unwilling to budge on features that are less than necessary or may seldom be used, the project runs the risk of going way above budget, both in time and cost. The completed system may suffer in quality and efficiency and will be much more costly to maintain.
Be Smart, Build It Simple
When designing a system and writing requirements, it is just as important to figure out what should not be in the system as what should be included. It may be easy to add more, but simplicity by definition means having less.
Albert Einstein, one of the greatest scientific minds in history famously said “everything should be made as simple as possible, but no simpler”. Leonardo Da Vinici said “Simplicity is the ultimate sophistication.”
Be smart. Do the right thing when designing a system. Make the hard decisions and really strive to remove any feature that is not absolutely necessary. It’s hard to make things simple. It takes a lot of work, but the success of your project depends on it, and it’s definitely worth it. After all, as Antoine de Saint Exupéry said, “perfection is reached not when there is nothing left to add, but when there is nothing left to take away”.
