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.
Next page: Complexity can hide bad practices