When good software gets complicated
Build for simplicity
A lot of recent articles have raised the issue of complexity in software (here, here, and here). So why is this subject back again? Surely it's been done to death? Apparently not. When I carried out a quick straw poll of some developers recently, few of them actually thought about avoiding unnecessary complexity in their software.
Keeping it simple
Personally, I am a really big fan of KISS - "keep it simple stupid" - but what does this mean? It means aiming to produce software that is as simple as is achievable, but that still gets the job done. And actually, the ability to keep it simple is certainly not stupid. It is, in fact, a very hard thing to do and requires a great deal of skill.
Why is this? Surely writing simple software is, well, simple. The trouble is that what we really want to do is not just write simple software, but write potentially complex ideas, logic or applications as simply as possible.
Thus, an algorithm to predict future trends on the stock market based on the use of techniques from artificial intelligence (AI) such as Genetic Algorithms may be inherently complex, but the key is to write that software as simply as is possible.
Why try harder?
Some of the developers I questioned above asked "why should I bother – surely as long as the software works that's enough right?" Wrong. Someone has to maintain the software, someone may need to extend that software, and someone may need to fix bugs in that software (perish the thought). The more complex the way it is implemented, the harder it will be to maintain.
As an example, I was once running a project that used evolutionary ideas taken from the AI field to identify and predict fraudulent mortgage applications. This was written in Java.
On the project, I clearly remember trying to convince a very talented and skilled developer that using a set of binary flags within an
int to hold information about the state of the system was not a good idea. I proposed the use a set of boolean instance variables to do the same thing - each with a meaningful name - within a State object.
However, he was convinced that using a single
int with each bit representing part of the system state was far more efficient, used less memory, and could be implemented using bit wise operations resulting in faster processing.
The problem was that the other developers on the project were from data processing backgrounds and were not comfortable with bits and bit wise operations. For them this was definitely not the simplest design. Note that the application spent the majority of its time waiting for the results of database searches and in terms of performance this was the greatest bottleneck.
In the end his solution was replaced by something that replied on a much higher-level representation, was still fast enough, and went through four or five generations of development without any problem. In my book, the second solution was by far superior.
Complexity can hide bad practices
Another reason to keep it simple is that simplicity often highlights poor design or implementation at an earlier stage.
I was recently reviewing some code written by an offshore development team. In examining one particular set of functionality, I found that the complexity in the way they had implemented their solution made it hard to determine what was going on.
By refactoring the implementation, with the aim of simplifying the implementation, I gained not only a better understanding of what the software was trying to do, but uncovered a number of strange behaviors hidden by the complexity. As a very simple example, it turned out that in the course of the implementation, the code did the following (this is intentionally simplified to illustrate the net effect):
String count = “32”; …. cut lines of code … int i_count = Integer.parseInt(count); … cut lines of code … String countStr = i_count + “”;
Without the intermediate
int value actually being used.
Simplicity can be copied
Yet another reason to keep things simple is that the first time you design and implement a solution to a problem you may well be doing so to solve a particular problem.
However, this may then become a blueprint to others on how to solve the same or similar problem elsewhere within the team, project or organization. If the solution you create is as simple as it can be, then not only will this approach permeate across the organization, but that "copied solution" will be easier for others to understand.
You'd be surprised the number of times I have heard the answer "I did it that way because that was what was done before" when I have asked (particularly more junior developers) why they adopted a particular approach. When this is followed up with a question about how the solution works, on more than one occasion I have received the answer "not sure really".
My final comment on keeping it simple is that you should be careful not to over-engineer solutions. That is, you should only implement what you need to implement and not attempt to anticipate future needs. Not only may those needs never actually materialize, but they also make the software more complex and more difficult to understand (not least as anyone looking at the code later on may fail to understand why the additions were included).
There are many reasons for keeping things simple, but there are also exist a number of "pressures" that may limit the simplicity of the solution. These pressures can include the desire to produce some fun code or to “impress other programmers” with your skills. At the end of the day, though, it’s the simplest code that may actually be harder to write than apparently more complex - but potentially less thought out - code. ®