The KISS of Death!
If you are building a complex product for a complex problem, you may want to think again.
A couple short anecdotes to start off this post. The first is about Chris Crawford, who is a legendary game designer and created some of the earliest computer strategy wargames in the 1970’s and 1980’s, including a tank battle game called “Eastern Front” which was developed in 1981 for 8-bit machines like the Atari 800.
Chris later wrote an article in 1982 for Byte Magazine about the development of this game, including a problem he had with tanks getting stuck in “U-shaped” lakes, where the AI code would send the enemy units into areas they could not path find around. He tried to solve this with better AI code, but had trouble, given the limited processing power and memory on those machines. His solution? Get rid of “U-shaped” lakes. He redesigned the battle map to just avoid the problem, left the AI as-is, and shipped the game.
Second anecdote is about my first job in college, working for the audio/visual center which at the time dealt primarily in film and film projectors. As employees of this school department, we would roll projector carts around from various depots to classrooms, show movies, and then take the projectors back to the depots when the film was done. (God that sounds so old-timey, even to me.)
A coworker of mine had shown a movie and took the projector out afterwards, to go back to the depot to rewind the film. (Rewinding in class was a no-no because it was noisy and would disrupt the lecture.) As she rolled the cart into an elevator though, the film slipped off the take-up reel, fell exactly through the slot between the elevator and floor, and went tumbling down four stories, trailing film the whole way because the other end was still on the projector.
In a panic, she sent someone for help, and I and our grad student boss Mark rushed over to the building, and found the elevator alarm ringing as it has been forced to stop for the past half hour, and found our coworker, crying. Mark was a no-nonsense kind of guy, and after surveying the situation, made a command decision. He took the other end of the film reel off the projector, and dropped it down the slot. Instead of hours of holding the elevator, digging up maintenance workers or whatever the other solution might have been, we went back to the office, reported a lost/damaged film, and the day went on.
What do these two stories have in common? The principle of KISS. Or as the proper acronym, K.I.S.S. — “Keep It Simple, Stupid”. Pragmatic, effective solutions to problems that sometimes end-around the “right” way of doing things. KISS can be a super productivity boost to an engineer that applies it properly, and can also cause disaster if applied recklessly.
But I am not going to go into detail on times I have seen KISS taken too far, and any problems that arose from that. Instead I want to talk about another negative consequence of KISS, which is that it can sometimes kill products. And just because I call it a “negative consequence” does not mean that this is all bad. “Negative” here is a relative term. It is certainly negative for whoever works on a product that is not successful, yet overall the idea that simplicity is a better solution than complexity is a good one —and dates back at least as far as William of Ockham, and his famous razor. But make no mistake: KISS can KILL.
People always underestimate the resourcefulness of people. What I mean is, we as individuals constantly underestimate our ability as a species to overcome big problems. The Y2K bug was a great example of this. It was supposed to be this cataclysmic disaster where all computers stopped working because the assumption a lot of code had that a 2-digit year field would always progress numerically forward. When the 2-digit year went from 99 to 00, this did in fact break a lot of code. But a lot of these fixes were simple, and a lot of this code didn’t completely break and only had minor issues, and a lot of things could just be replaced or ignored.
So we all waited nervously on New Year’s eve, 1999, and nothing happened. The scare was, in my opinion, a huge underestimation of the human ability to mitigate or overcome threats via pragmatic means.
What if the problem that is being averted though, is something someone is trying to make money off of with a product solution? Then there is trouble, because one person's desire to make money on a product runs headlong into another person's desire not to spend money if they can avoid a problem.
Even the most elegant and carefully-architected products can flop, if there is a simpler, cheaper solution available. And creating a product for a problem that can be avoided by some pragmatic means is, unfortunately, somewhat commonplace.
A couple more anecdotes, from my personal experience with “The KISS of Death”.
Back in the early 1990’s I worked on the development of a line of computer workstations, based off of a new chip called Alpha designed by Digital Equipment Corporation. Alpha was a very early Reduced-Instruction-Set-Computer, a.k.a. RISC processor. The world today is largely powered by RISC processors, made by a company called ARM, not Digital. In the 1990’s however, RISC was a cutting edge technology, and ARM was only a tiny startup company.
The processor landscape was almost completely dominated by Intel at the time, with other companies like IBM, Sun, HP and Digital trying to defend their custom-processor workstation territory from Intel’s cheaper and increasingly more powerful chips. ARM would be successful later at breaking this monopoly by producing chips that were more power-efficient, and superior for the mobile market. But in the 90’s, the mobile market did not exist, and the name of the game was speed.
Digital’s Alpha processor was fast. Faster than Intel’s Pentium processor of the time, but Digital faced strong headwinds selling it, because it required customers with Intel-based applications to either port their software to Alpha, or use an Intel emulator which was often not 100% compatible, and also obviated some of the speedup one got with Alpha. Performance for integer calculations for Alpha was about 20% faster in some benchmarks, but 20% is not nearly enough to get people to switch.
Floating point performance was another matter. Intel’s architecture had a floating-point performance weakness, and Alpha chips were 2-3X faster at doing floating-point operations. That kind of speedup was compelling, and Digital felt our Alpha workstation products could be aimed at scientific, engineering, and graphics processing applications that needed to work in non-integer numbers.
3D design Applications like SoftImage and AutoCAD were logical choices for Digital to go after, since people frequently design things with fractional dimensions like 1.23 millimeters and not just whole numbers like 1 or 2 millimeters. We thought Alpha was going to kill in the benchmarks on these apps, given our floating-point superiority. But after convincing, (and often paying) companies to port their 3D applications to Alpha, the benchmark results against equivalent Intel versions of the software were only marginally better, or in some cases not better at all.
What Digital found out was that performance for floating-point calculations had long been a “U-Shaped Lake” for these Intel-based applications, and the companies that made them all did the same thing Chris Crawford did: they eliminated them. It turns out that you can easily represent a number like 1.23 as an integer, using fixed-point arithmetic. You just call the number 123, and remember where the decimal goes when displaying it. Thereafter, the integer arithmetic logic unit (ALU) can be used exclusively, with no need to slow things down for floating point calculation.
Floating-point calculations are of course still superior to fixed-point for certain situations, especially those where you do not know the scale of the numbers you will work with, or if the range of numbers you calculate with is exceedingly large. In these cases, it is very handy to use floating-point, because it stores and processes the number data (mantissa) and scale (exponent) data separately, to avoid loss of precision.
But for many, many use cases, fixed-point arithmetic is sufficient, and the user can often supply the scale they wish to work in up-front, which makes it pretty easy to maintain precision when doing calculations. Digital’s bet on floating point was killed, by KISS. And eventually, so was Alpha. Not only due to that of course — going up against Intel in the 1990’s was probably a lost cause for any processor maker. Had it been 10 years later when low power design became critical, maybe we would all be running our phones on Alpha, who knows.
Second story is very similar, but I provide it just do demonstrate that the “KISS of Death” is not limited to hardware design, or the 1990’s. A much more recent product I worked on was a Hardware/Software co-debugger, that allowed users to run and debug software on chips that had not been built yet. Such a tool was intended for manufacturers of processors who needed to develop low-level code for upcoming processors that were still being simulated prior to manufacture.
This idea was pretty slick, as it allowed developers to set breakpoints in a pretty seamless way in both their hardware simulations and in their embedded software, and really dig in to complex situations when you are unsure of both your hardware and software design, and need to know where the bug is. The technology to do this turns out to be quite complex, and could demand a high price - and it did in fact end up getting more successfully applied in other related products later.
But this one was also killed by KISS. The assumption that there would be customers designing software for chips not yet built was a correct one, and of course this software like any other had flaws, that needed to be debugged. But what doomed this particular debugger product was that hardware/software co-debug is a “U-shaped lake”, and our customers had already found simple ways around this difficult problem. For instance, using a previous generation of real, non-simulated processor hardware to debug the new software, using ubiquitous and free tools like the GNU debugger (gdb).
By eliminating the need to simulate hardware while simultaneously debugging the software, these companies had reduced the problem to one of software debugging only, and many software debugger flagship products have foundered on the rocks of free debuggers like gdb. This software-debug-only solution was of course not perfect, but using this pragmatic approach companies could cover the bulk of their debugging needs, and live with a few complex debugging situations once in a while without having to buy a (pretty expensive) custom tool.
I myself have given the KISS of Death. Once when Digital was switching CAD tool vendors, we needed to move our PCB libraries from one format to another, and the new company was going to charge Digital $2 million in contracting service fees to do it. I spent a week writing an awk script that did it for free (or comparatively close, my hourly rate x 40). Digital then proceeded to drop the contract, faster than a film reel in an elevator shaft. There may have been a few contractors who lost their jobs over that one. But I was mad about the cost of it all, motivated, and ready to be simple.
So in summary, if you are thinking of creating a product, you might want to first talk to the biggest cheapskate you know, and ask them what they might do to avoid paying for your solution. If they can’t come up with a simple answer, that is a good start!
Got your own “KISS of Death” story? Love to hear it!
Explore Further
Coming Up: Thanks for the Memories! A look back at the weird, wonderful world of computer storage devices over the years. Find out what’s in store next time in, appropriately, What’s in Store?
The Mad Ned Memo is published on a (more or less) weekly basis, and features nerdy tales and discussions of computer technology. It frequently trends on technology-loving social media sites like Reddit or Hacker News, but you don’t have to chance missing out on an issue if you subscribe! It is cost-free and ad-free, and you can unsubscribe at any time.
The Mad Ned Memo takes subscriber privacy seriously, and does not share email addresses or other information with third parties. For more details, click here.