What I understand as over engineering

As software developers we have a double challenge when we write our apps. We must write working readable code, and on the other hand avoid over engineering. In our environment we often refer it as ‘sending a rocket to the moon’. Obviously, when sending a rocket to the moon is not not the requirement, although in most cases that’s not what we are asked to do. To be more precise, what I understand as over engineering is to make sotfware more complex in order to solve problems we don’t really have, and that we are not likely to have in the future.

How to detect over engineering

I can think of several ways to detect over engineering. The first that comes to my mind, a bit useless, is how many software design patterns we applied to our code that don’t answer to a real trouble we are trying to solve. Both the lack of design patters and the abuse of them ar signs of bad code. Design patterns are tools that try to fix a concrete problem in software design. If we use them to solve problems we don’t have, we are just getting our code more complicated and unreadable.

As I mentioned before, detecting this once the code is written is quite useless, because while we can refactor, doing so implies an adittional effort. So, how do we detect over engineering in an usefule state of development?

Detecting over engineering in an useful situation

The most useful state to detect over engineering is when we are thinking about design and writing code. That’s the precise moment when the problem arises. How do we detect it before it’s late? I can’t provide a concrete way to do it, but I do have some situations I use as a pattern to raise alarms:

• Ask myself: What problem am I trying to solve? What objective does my app have? Is this design solving that, or getting it worse?
• If I am using a design pattern, it must be emergent from the problem to be solved.
• Ask myself: how can I make it simpler? Over and over again. There’s always a simpler way.
• If I can’t find other simpler designs, I ask a colleague. Sometimes just explaining the problem to another person makes you come up with the solution
• When designing, go for a walk, have a good night of sleep, or even a short nap with your eyes open. We sometimes suffer of tunneling vision. Let the right part of your brain do the job.
• If you say or hear “Let’s do [bla bla bla] just in case [ble ble ble]” raise the alarms. It’s good to make robust software, but we also have to prioritize which problems to solve.

So what do I do now?

I propose you the next time you write a single line of code, ask yourself:

What am I writing this line for? If you have an answer (a real one, not a forced one) ask deeper: what am I writing this function for? You have an answer? Go deeper: what am I writing this file for? You have an answer? Go deeper: what am I writing this user story for? You have an answer? Go deeper: what am I writing this software for? It is usual to run out of answers in some point. That’s the right moment to replace that line of code with a conversation. It can be with a partner, with a functional Analyst, or even with a user, because if we loose focus on the main trouble to solve, we might be suffering of over engineering.