The KISS philosophy: Forgotten but still needed.

     As an engineering executive/manager, I had a developer once come to me and say "here it is. I have fixed the last bug". I smiled and said "well, I can't wait for the next-to-last bug" recognizing that, if we counted that way, we would never reach the first bug.
     All software has problems (not isolated only to software -- but it is particularly prevalent in software). Even if somehow the program was simple enough and used for a long enough period that all of the problems within the program were fixed, a program does not exist in isolation. It will interact with other programs and the hardware. Change those and problems may easily surface.
     The primary criterion that creates the situation where software always has problems (or "bugs") is complexity. A five line program may eventually get all possible interactions tested and all known problems fixed. A 200,000 line set of programs (or processes) has little chance of even having all the problems known.
     There is an anecdote about Bill Gates talking to a developer at Microsoft. He is said to have said "Don't worry about the size or the amount of memory needed. By the time it is finished, we will have faster processors with greater amounts of memory." A side effect of this (loved by sales, disliked by consumers) is that new programs usually require new software and hardware to perform at their best.
     On the flip side of this issue, Soviet developers used to have a reputation as being very good programmers. They were required to use older computers with much less memory and they had to share equipment such that they had only certain time slots in which they could compile and test their programs. These constraints in equipment forced them to be much more careful in their programming as well as making the programs small and efficient.
     In the world of programming and marketing, complexity is also sometimes referred to as "Creeping Featurism". Marketing and Sales demand new features that can be used to distinguish a program from that of the competition. However, each new feature increases the complexity of the program and the system -- and the complexity does NOT go up linearly -- an increase of 5% in the number of lines of code may double the number of initial problems to debug.
     This might eventually be of general benefit if it wasn't for the fact that many features go unused by most people. They may not even know they exist -- or, if they do know about existence, they don't know how to use it. If this is so, why add the extra features? The answer to this is that word "most".
     Assume that a program has 200 features. Twenty of those features are used by almost everyone. One user makes use of 40 features. Another user makes use of 50 features. But only 1 of the 20 "extra" features of the first user is the same as user 2's 30 "extra" features. The others are used only be the particular user.
     When I was a beginning programmer in the 1970s, all of our courses emphasized using the KISS philosophy. The acronym KISS stood for "Keep It Simple S_____" (substitute your own favorite S-word). It was a reminder of the discipline that was expected (and that the Soviet programmers had to have as a requirement). 100 lines of code that did a function was much better than 300 lines of code that performed the same function. It was easier to debug (and usually had fewer bugs in the first place), faster, and required fewer system resources. KISS fell victim to the expectation that Moore's Law would always hold -- that processor power WOULD continue to increase and that memory would be cheaper and cheaper. But being ABLE to function does not imply that is was written as well as it could have been.
     Although the KISS principle was created in connection with software development, the same holds true for other complicated, interconnected things -- such as laws and regulations or industrial factory processes.
     Do you work with the KISS principle? If so, why? If not, why not?