Hello everyone, in this article I will talk about over engineering and the price it costs to any project, plus I’ll discuss about identifying and how to avoid doing it.

On first, let’s simply define the term over-engineering as the act of providing or creating a solution to a problem that other more simpler solutions could solve the problem with the same effectives and manner. In other words, means that when you design a new system or implement some new technology without thinking of the costs and trade-off or just using it by the hype, you’re doing over-engineering.

But, what’s the problem with that? Isn’t using the new hype technologies or adopting Big Tech solutions the right way to solve software problems? Well, knowing new technologies is really a thing with us engineers, when we see an elegant solution or a breaking ground framework, we almost want to adopt it and experiment in many ways. Doing that in personal problems or proves of concept is quite okay, the real problem becomes when you adopt it as the definite solve for any situations at the work.

Software Engineering, in any step of the chain, since design the idea or codding, costs money, a lot of money to be honest. Most of us reads Netflix’s, Amazon, or any of the FAANG tech articles and then the eyes sparkles and the first thought is “Well, let’s apply that to our company, so our product will grow up jut like theirs”. In most cases, that think will lead to project failures.

Every company and any project have their financial state, technological state, and team moment. Everyone is different and has their own peculiarities. So, applying those new technologies just for experiment can turn projects into truly chaos. You need to think that any solutions come with a cost called TCO – Total Cost of Ownership, which means that you’ll pay not only for the development teams, but for maintenance, training, and license if there’s any. The sum of all costs resolves into the TCO. All over the time, the first developers that worked on this innovation can leave or be in other projects, so you’ll have to pay more and more in TCO. The Overengineering price is when you are in this snowball situation.

To be honest, I think that every software engineer will commit that in one moment of its career, so the true question is: how to avoid?

In this diagram I try to bring you all a flow diagram chart that I hope it helps you and your team to identify when the time is to implement innovations or use an cheaper and already tested solution.

Talking more about each step, in the first decision it’s the moment where you have a engineering problem and you should start to search for solutions for similar or same problems. When you reached it, you’ll think about the company moment, and when I say about company moment, means either the technical, cultural, and financial moment. Maybe that solution you found is a good one, but the teams are not technically ready yet, or the cost of maintaining in a cloud provider would cost too much.

Looking at the left-side of the chart we have that iteration flow, we look for a solution, look if matches the company moment and if no restart the search. On the right side, we have the innovation ground. When, and only when, there’s no solution for similar problems, your team have a good technical background and your company is in a good moment, then you can bring new or bigger solutions to the table. And if you did not find any solution and if is too risky to your team leads with the new challenge. Then you need to step back and rediscuss the project, probably breaking it into minor parts and more projects.

So, if you or any team member try to skip some steps of this flow, it will certainly cost your over-engineering.

Of course, this flow isn’t the silver-bullet for all process, but it should help you to think about the engineering and fit it to your costumers demands.

Hope you liked it! And even about software engineering costs, or IT costs, how about reading this article about the most expensive part in software development ?