In my 6 year career as a software engineer, I have had the privilege of working with all kinds of people involved in running tech companies or building tech products. Talking about the different kinds of people I have encountered is a whole other story so I won’t do that now(read this as a starter on managers).
However, there is a trend I have observed with experienced and good software developers. It’s popularly tagged overEngineering.
I’m not writing this to imply that people should not write good code, develop good frameworks, create great documentation for products or tackle complex problems altogether, NO…
All I’m saying is:
Do not overEngineer
So what does it mean to overEngineer?
Let’s analyse it from a much larger scope and then look down into coding.
Consider this scenario: a client brings a problem to a software development company and the company kicks off their typical development cycle to build the product for the client.
You’ll see that right from the first person who heard what the customer explained, some complication was added to the simple task of hanging a tyre (what the customer wanted).
Alright, let’s bring it down to the specifics of programming.
Imagine a startup that is still formulating its business model or one that has neither scaled nor is making sufficient revenue. If a developer, newly employed by such a startup, attempts to build the company’s website (website, not web app) from scratch using React or if the developer attempts to use Test Driven Development (TDD) to create the Minimum Viable Product (MVP) of the company’s core platform (no one has used it yet thus there is no proof that the solution will be accepted) then you can already smell overEngineering. This developer is complicating a very simple task of building a website or getting an MVP ready (respectively).
If you look closely, you will find that the crux of overEngineering stems from a general problem I have observed about people. People try to complicate simple things because they can.
Why you shouldn’t overEngineer?
I know a developer who used one month to set up a deployment pipeline for a software product we were working on. In all fairness, what he tried to set up would have been very good to have but I implored him to focus on the main product first and then we can optimise the deployment process later but, well, he didn’t listen. Eventually, we missed our deadline and the developer, well, he had to be let off the team.
If we had focused on solving the problem and building the product, maybe, just maybe, we would have met our already tight deadline…
So here’s a reason you shouldn’t overEngineer. Apart from the possibility of failing your tasks, when you overEngineer, you end up creating problems that you never had…
How to identify overEngineering?
It’s hard to tell when a solution is being overEngineered but there are simple litmus tests that you can use to know when you are overEngineering.
There is a basic principle known as the Pareto 80:20 principle that implies that 80% of your output comes from 20% of your input. This means that of everything you do towards achieving a goal, 20% of your effort actually accounts for 80% of the results that achieve your goal. This means that if you pay more attention to the 20% that works and not the 80% that doesn’t really account for much (I’m sure overengineering lies in the 80% piece of the pie), you are sure to get a higher chance of success and even better results.
In simpler terms, as the mathematics here may be somewhat confusing, it will come to you intuitively that you are doing so much for so little and when this happens, you have overEngineered.
I’ll leave you with this little nugget…
The essence of engineering is solving problems but in truth, solving one problem naturally brings about other problems. For example, we never really cared about global warming till we invented cars.
So please, let’s not create excess problems for ourselves by complicating simple things (overEngineering) but instead focus on creating solutions.