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?

Ready, Set, Stop

We've probably all seen a car in an intersection -- rear end over the crosswalk and front end partially blocking the outside cross traffic land -- and they just stay there, never getting a green light to go. Or perhaps they have stopped 30 feet behind the crosswalk and they're stuck (and you're stuck behind them). There really is no mystery -- they are beyond the range of the sensor in the road and the traffic light system doesn't know they exist.

Traffic light systems are ideal for computer programming assignments. The basic system is very simple but it can be increased in complexity to understand more and more possibilities of design. I have used such systems as examples in a couple of my books.

The simplest form of traffic light is a blinking four-way stop (red lights). Not much of an advantage over a four-way set of stop signs except more visible in the dark. The next version can make use of a simple mechanical timer and set of switches (rather like many mechanical pool pump timers). The timer can revolve at a fixed rate and close contacts with the appropriate lights in the traffic system. It probably proceeds like

Green Red
-t- Red
Yellow Red
Red Red
Red Green
Red -t-
Red Yellow
Red Red
and back to the beginning. The "-t-" indicates some type of delay -- the length of time that the green light stays on for that direction. Note the two times that both directions are Red. This is very important for safety reasons.

This simple mechanical system has a timer and a set of connections to lights. The timer is an input and the connections are outputs. Mechanical systems can be designed to allow for a beautifully complex set of conditions but the actual construction becomes more and more precise and difficult to mass manufacture. It is much cheaper, and easier, to start adding microprocessors and programs to handle more complex operations.

With programming, the inputs are often extended to a clock, a set of timers, and one or more sensors. These are all concerned with events that affect the output -- which may be extended to include walk lights in addition to traffic lights. The programming may start taking into account the day of the week, time of day, whether it is a holiday, how many cars are waiting in a lane, and many other options. Once again, it can get pretty complex -- but most of the complexity is hidden in the programming and, thus, mass manufacturing is still possible (even reduces the cost per unit when more are made).

So, the car is stuck because the sensor no longer can tell it's there and it cannot use that as an event to trigger a light change.

Why go into all this detail? Who cares? Well, I find it interesting in itself but it's also a good prelude to talking about embedded processors in cars and the relation between complexity, sufficient testing, and safety which is definitely in the news of late. See the next blog .