KISSS
Originally published on macresearch.org, around 2007. Reproduced from the author's archive; some links may no longer resolve.
Acronym of the Month: Keep It Simple, Stupid (KISS)
Devoid of any decent content to publish on MacResearch this week, I thought I would just rant a bit about a very commonly used acronym in scientific software development: KISS. KISS stands for ‘Keep It Simple, Stupid!’, and whilst I love the sentiment — it’s basically a rewording of Occam’s Razor, a fundamental principle of scientific endeavor — I have come to despise it over time. I’ll now explain why.
The Mac OS X dictionary app defines Occam’s Razor as
the principle (attributed to William of Occam) that in explaining a thing no more assumptions should be made than are necessary. The principle is often invoked to defend reductionism or nominalism. Compare with principle of parsimony at parsimony.
The KISS principle was no doubt originally intended to echo this sentiment: keep your solution as simple as possible. I have no qualms about this objective; it is a fine mantra to live by, that is, as long as you don’t take it too far…
See, I often find the KISS principle being used against me to defend ignorance, so much so that I now have a different definition of KISS: Keep It Stupid, Simple! The intent of Occam’s Razor, and presumably KISS, is that you should seek out the simplest solution to achieve a given objective. But I often find people using it to argue the case for a simpler objective, usually because they don’t understand the technology required for a more advanced one.
People often associate an advanced technology with something that is ‘complex’, whereas usually the opposite is true: advanced technology is designed to make difficult things easier. That usually comes at the cost of having to learn the new technology, but this is relatively easy compared to reinventing the wheel.
Let’s take a simple example: many Fortran developers fight tooth an nail to stick with the Fortran 77 variant, even though it is now 30 years old — a millennium in computing terms. Fortran 77 is ‘simpler’ than Fortran 90/95, in the sense that it has less functionality. It is true you can generally understand the impact of every statement in a Fortran 77 program, because there is no high-level abstraction at all. You really are only one step up from the assembler level, with no user-defined types, array expressions, or even memory allocation.
You can certainly solve any problem in Fortran 77, just as you can solve any problem in assembler or machine language … if you’re patient enough. Ninety percent of the activities you will need to undertake in your Fortran 77 program will be repetitive duplication of constructions, which are not only unnecessary, but also error prone. You will be taking on tasks much better handled by a compiler. Sure, you have a ‘simple’ language, but the task of building an advanced application with it is that much more complex as a result. You haven’t kept it simple, you’ve kept it stupid.
Adopting a more advanced technology, like Fortran 90/95, requires additional learning. You have to buy a book and read it. But ultimately it saves time, because you will waste less effort actually developing your application. In this scenario, you are using more advanced tools to achieve a simpler solution. The same could be said of scripting: adopting an advanced scripting language like Python or Ruby requires you to invest time learning it, but ultimately it makes your solutions simpler.
In that sense, KISS still applies, but you need to recognize that it covers the complete solution pipeline, not just any one part of it. The question you need to ask is ‘What is the simplest solution in the long term?’ If you’re honest, you will probably conclude that it is better to learn a new technology upfront, and reap the rewards over the years to come.
To finish off, I want to mention another, closely related acronym: Don’t Repeat Yourself (DRY)! This one comes from The Pragmatic Programmers, and is probably more useful that KISS, because it gives practical advice. (If you’re a developer, and have never read The Pragmatic Programmer, order a copy today. Highly recommended.) The DRY principle says that whenever you see some sort of duplication in your program, or anywhere else for that matter, you need to try to remove it. For example, if you find two very similar pieces of source code, try to create a subroutine for it, and invoke that subroutine as appropriate in your program.
Many of the benefits of ‘new’ technologies like Fortran 90/95 are that they help reduce duplication. Where in Fortran 77 you typically use common blocks to store variables, which require you to redeclare them in every scope that they are used, in Fortran 90 you can declare them once in a module, and ‘use’ that module elsewhere. The redeclaration of variables is a form of duplication, and Fortran 90 gives you a language supported means of removing that duplication. And that is just the tip of the ice berg; there are many other such examples.
In conclusion, do DRY, and by all means KISS, but be a little more discerning about what you KISS.