I teach Computer Science at the college level for high school students. Teaching can be a challenge, but it is very rewarding. What got me to thinking about “Keeping It Simple” was helping students with C++ and Java homework. I recently assigned a challenging problem in each class. Both languages use dividing code into subsections called classes to allow related code to be put together into single modules. Those modules are then put together to create a program that a user can run. What I have found in each class is that too often students try to over-think the problem. They sometimes produce a good but very complex solution. Complex solutions are hard to maintain both for the original programmer and anyone else who takes over the code. The most elegant code is the opposite, it is as simple and as straight forward as possible. One common phrase used where I have worked is “Keep it Simple, Stupid!” I prefer to rearrange that to “Keep it Stupid Simple!” In companies, it is important to ship a good, usable product as quickly as possible. Look at what the product (or for students, assignment) is supposed to do and then do that well. “Bells and Whistles” can be added later, but do the best simple design first. Customers really appreciate products that can solve their needs and have that quickly. Keeping it simple does not mean compromising your standards and rushing the product, but making the best product possible.
An example that shows both the advantages of keeping it simple and rushing the product to market is illustrated by the competition between McDonald-Douglas, with its DC-10 and Lockheed with its L-1011. In the 1970s, they competed in the market for planes larger than Boeing 707s and DC-8s and smaller than Boeing 747s. MD focused on keeping the design simple and safe enough. Lockheed was producing military aircraft and so was more concerned with making the best possible design as safe as possible. MD was able to come out with their plane first and even airlines, like Delta who wanted to buy L-1011s, bought DC-10s as a stopgap. Overall, they both had good safety records and the first one to market received the lions share of orders.
The C++ students have already taken one semester of programming the language and so have the basics mastered. The purpose of their exercise was to work in a group using GitHub as the repository for their code. They were assigned to work in groups of two to three and divide up the code accordingly. The actual assignment was to build a generic Account class with most of the storage of information and routines to do the main functions of an account. They then were assigned to create a checking account, savings account, CD account, and mortgage account. In Java and C++, an Account class can have what are called subclasses which can use the variables and functions from the Account class and only add or modify what is needed to make the Account class perform the functionality for each of these specific account types. Keeping it simple means knowing who is doing what and tracking each person’s progress as well as writing simple code that does the job well. Some examples of added complexity to a problem are:
- Not following through on what was promised and causing one person to do the majority of the work.
- Reprogramming the code from the Account class in each of the subclasses.
- Using complex algorithms when more direct methods could be used.
In the Java class are all students with very little to no programming experience. The students have been doing well with the assignments so far, so I decided to give them a more challenging assignment. They were to create a Mancala board. I presented an example of the code to the class and some followed it exactly. But there were some interesting variants. One was quite good where the user decided on a different format for presenting the board and that solution presented the information for the board well. There were others, though, that tried to make the problem more complex than it really is. I showed the students several one-dimensional arrays to solve the problem. Since the students are new, a few struggle to implement a solution and made the code more complex than was needed. One created a giant two-dimensional array to try to handle everything. After working with this person, s/he was able to reduce about 15-lines of code down to about three lines, which was much easier to understand and did the needed job.
Remember to “Keep it Stupid Simple” when doing something important. This is actually an old philosophy for many things beside programming. It was first attributed to a Franciscan monk, William of Ockham. Occam Razor states that the simplest explanation is usually the correct answer. “Keep it Stupid Simple” and you will do well.