Simplifying as Much as Possible is the Way to go in the Engineering Industry

The more complex a solution is -> more 💰costly it is for the business!

Intro

In the world of engineering the term complexity may seem to sound good right? The more complex a certain thing is, the more “wow” effect it has.

Well, all of that complexity comes with a cost! And the cost can be huge. The more complex a certain thing is, the costlier it is for the business to ensure it works correctly.

Is complexity something we should praise or we should avoid? Let’s get into that next.

It’s common in our industry that complexity is praised, but that’s not the way to go

It's quite common in our industry that a technically complex solution may get approval or praise from others, especially other engineers.

Being clever or trying to solve all of the future problems ahead of time may seem like a good thing, but this may provide more problems than actual good things.

Complex technical solutions should not be praised because they are hard to maintain, hard to understand or just too complex overall.

It's really important to understand that we are here to provide as much business value as possible. That is our purpose. Amazing technical solution may not contribute to that.

I have made the mistake of thinking that complexity is a good thing a LOT of times in my career as an engineer

This was especially prevalent in my early days as an engineer and when I became a bit more confident in my skill set. I thought that I could build anything that I wished to, therefore I thought if I put a bit more effort in the beginning, I could solve all of the future problems.

Well, I was very wrong. For example: I’ve built an abstraction (a reusable component) that was only used one time in the whole application. It kept being used only once until there was the need to adjust it a lot for the second time.

I tried to make all of this possible in the abstraction, which I did, but it became very complex.

Well, what happened next, was that there was a requirement to use it for the third time and it was completely different again. That’s where I needed to refactor and split this abstraction into 3 different cases and it took a lot of time to do that.

I would avoid this completely if I would:

• Keep it simple in the beginning with no abstraction (KISS method).

• Didn’t try to predict or solve future problems that may not even exist (YAGNI method).

You can read about all of the main mistakes I made as a junior engineer here: Starting my career again as a junior engineer (paid article).

I have made the mistake as a manager that a complex process is needed

When I first became a manager, I thought that I could change so many different things for the better. With the best intentions in mind, I added additional steps to our software development process → using epics and sub-tasks.

What happened was that in our case it was a bit over-engineering and there wasn’t a good way to visualize the progress on different sub-tasks.

We ended up losing some important tasks, because of visibility issues and that contributed to more issues than good things.

So yes, similar learnings than before. If something works, don’t change it. Try to keep the process as simple as possible.

The more steps and complexity you add → the harder it is for people to remember all the steps and also onboarding new people is tougher as well.

Processes should be introduced to help not to add complexity.

You can read about all of the main mistakes I made when I grew to the manager position here: From IC to manager (paid article).

Simplifying as much as possible is the way to go