Over engineering is a major problem within the software industry. This problem has led to the adoption of ‘lean software development’ – at least amongst the agile folk. Lean software development is writing code to support the current set of requirements and nothing more. This is not as easy to do as one might think.
As developers we naturally tend to make assumptions as to what the user, or system, will need. In truth, it is very difficult to accurately predict the future requirements of a system. Coding to meet our assumptions will inevitably lead to over engineering.
We should not let our intuition guide us into false requirements. As strange as it may sound, it takes a concious effort to stop ourselves from doing extra work. We need to adopt a ‘lean coding culture’. We need to constantly remind our selves to stick to lean software development. In agile teams it is common to hear developers reminding each other with certain acronyms and expressions e.g. ‘do the simplest thing that works’.
‘Do the simplest thing that works’ is in-line with lean software development, although it can be misleading. Some people interpret this as ‘do the first thing that comes to mind’ e.g. slap on another if statement – that is a simplistic solution and not a simple solution. If you take a quick and dirty simplistic approach you will end up with a big ball of mud. You need to do the simplest thing that works. The thing that works is something that can be tested, it is something that does not add unnecessary complexity. Therefore the simplest thing that works is not necessarily the quickest and easiest thing to do.
When talking about lean software development we often refer to KISS (Keep It Simple Stupid). I agree with keeping things simple but I don’t like to be called stupid, the truth hurts. I prefer to use: Keep It Simple and Sensible. This is more positive and the sensible part indicates that we should give some thought to our code. For example, instead of littering your code with conditional statements you could refactor the code to use an established design pattern. Having said that, design patterns are not always a good idea.
You should not implement a design pattern unless there are real signs indicating that you need a smarter solution. It can be detrimental to implement a design pattern for the sake of having one. You are likely to implement the wrong pattern and that code will be a hindrance. Only do what you really need to do. This is also referred to as YAGNI.
YAGNI (You Ain’t Gonna Need It) – This is a term used by Russ Olsen in Design Patterns in Ruby. In this book, Russ Olsen does a fantastic job of explaining design patterns. He also explains when not to use certain patterns and the problems that come with using each pattern – After all, software is about trade off’s.
Russ Olsen explains that we should not write code or implement patterns in anticipation of a requirement that might emerge. Firstly that requirement may never surface, and if it does it may have a stipulation which makes the pre-emptive solution void. It is safer to code to meet the current and real requirements of the system. To drive this point home, here is a delightful paragraph from Russ Olsens’ Design Patterns in Ruby:
“Look at it this way: Barring a sharp blow to the head, as you stand here today you are as dumb as you ever will be. We are all learning, getting smarter every day. This is especially true in software projects: You can be sure that you will have a better grasp of the requirements, technology, and design of any software that you work on at the end of the project then at the beginning. Whenever you put in a feature before you really need it, you are guilty of programming while stupid; if you wait until you really do need the thing, you are likely to have a better understanding of what you need to do and how you should go about doing it.”
The moral is: Don’t be guilty of programming while stupid