Most over engineered solution EVER…

I recently saw this “ah hem” challenge posted on X:

What is the most overengineered library/tool/framework/environment that you ever used at work? —Mario Fusco

I looked no further than my own coding experience to find an answer!

Early in my career I had read the GoF's Design Patterns.

When I read it, it was like magic! Naturally I had to use those patterns. I was that impressed by those incarnations of OOP.

So in my next project, a small one with few fellow teammates, I began using them.

All of them.

My solution was probably triple what it really needed to be.

And there was no one there to tell me that what I’d built was ridiculous.

Later on when the anti-pattern movement arose and book after book was published, I realized what a foolish decision that had been.

I have since become a bigger fan of The Poutsma Principle.

Before I explain what The Poutsma Principle is and why YOU should adopt it, check out a word from today's sponsor...

Coding isn’t just about algorithms. There’s more. A LOT more. CI, security, team communication, meetings, career tips, you name it.

I wrote 12 Rules for Pro Coders to give you actionable advice to accelerate your career. As a veteran pro coder, I want YOU to learn the same valuable lessons I did…but faster.

This advice has been put to the test. In my own process of being cut in the acquisition, I have actually leaned into what I wrote in the midst of coming up to speed on my new endeavors over at Cockroach Labs. This book can help you too.

So grab your copy and learn what your university or boot camp didn’t have time to teach you!

Now back to our regularly scheduled article.

So what, exactly, is this Poutsma Principle that you probably have never heard of?

A tongue in cheek idea, it says that if Arjen Poutsma (creator of Spring's @MVC-based web controllers and RestTemplate among others the things) doesn’t understand what you wrote, you’re probably wrong.

A more serious phrasing is to not do “cute” stuff but instead to strive to make things as simple and straightforward as possible. And if you can’t find a less “hacky“ solution, perhaps you need to hold off on your supposed “solution”.

Complex and hacky solutions only put additional maintenance on our own plate and demand further hacks and tricks to sustain it. A keen consequence of "slick" stuff is that it may be very niche in where it applies. For a solution to have a wider usage and applicability, we need to look for simpler solutions.

It doesn't mean the patterns in the GoF book were necessarily wrong. But when we look at a pattern as having universal application and forget to apply reason and analysis, we can easily get in over our head.

What about you? What’s the most over engineered thing you have done?

If you’re a pro coder or plan to become one then stay tuned for my next article. But if you simply can’t wait then check out this video where we discuss whether or not Java is actually an okay language to learn!

-Greg