Please stop over engineering stuff

Warning, this post is polemic, but it has content that MUST be discussed.

Have you ever had to give maintenance to legacy code? Do you also want to cry when you see “that kind” of code? :D On today’s post we’ll talk about the art of over engineering.

When we talk about legacy code people usually get scared, and many times with reason.

Code not covered by automated tests

Whenever I have to maintain some legacy project, the first thing I look at are the tests. Automated tests are usually a documentation of the written code, so looking at the tests we can have an idea on what a class does, even better if we have BDD tests, because we’ll have the scenarios very well described which makes it easier to understand whats going on. But in reality, how many times did you look at a code and it was not covered by tests? This is the first worrying thing.

The design

Then we can take a deeper look into the code and try to understand the design of the project. There we usually see the second problem. The project structure is all messed up, classes are not properly divided into proper packages, or many times all of them are on the root package, top! You will see all kind of standards mixed up. Packages, classes and methods names written in a wrong way, or even with different standards.

OK, but let’s look at the design of the whole thing. If you start looking at a higher level, you will see all kinds of design patterns, even when it doesn’t make any sense you will see these patterns spread everywhere confusing the understanding. From here will see all kinds of over engineering to make simple stuff. Interfaces for everything, most of these with only one implementation, why? You don’t need to spread interfaces or use multiple inheritance everywhere just to prove you know it. Why not making a simple solution? Usually people say that it was written that way to make the project flexible … it really makes the project more complex, please refer to KISS.

Then you will look into the classes code. There you will see classes with +500 lines, code doing a lot of different things, with sub-classes and all kind of workaround together. All this not tested, with variables named “a”, “b”, “x”. With logs saying “passed thru here”, “worked”, “fail”. Uncle bob cries.

Who never saw it? Who never did it? :D

Please stop over engineering

Please, stop over engineering code, design and architectures just to prove a point. Please keep it simple. Please test your code. Please deffer design decisions and please do not prepare your code for everything, that’s bad.

Also writing a explaining what the project is, base design, how to run and additional details makes it much easier for new developers to understand stuff and start producing. But you hardly ever see it.

If you have any questions or want to discuss more, you can reach out to me on the comments section. I hope I helped a bit, thank you!




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Solving Concurrency in Event-Driven Microservices

How to Learn to Program: Writing Code Templates

How Apps Are Localized

Thumbnail image of me

Save the Environment with Anaconda

Keys and Constraints in Relational Database

Data-driven Software Engineering: Avoiding Common Problems

LRU Cache Behaviour Implementation in Scala

How to Build a Chrome Extension ?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Marcelo Cure

Marcelo Cure

More from Medium

9 Tips on The Bottleneck of Code Reviews

Design and Implementation

System context for the weather station

Don't aim to be an architect… Try to be a Lego Master

Gojek Interview Experience