DEV Community

loading...
Cover image for Do you have a habit of over-engineer your projects?

Do you have a habit of over-engineer your projects?

madza profile image Madza ・1 min read

Sometimes, by trying to achieve more and be a perfectionist, you might actually end up shooting yourself in the foot.

Do you have a habit of over-engineer your projects?

Discussion (28)

pic
Editor guide
Collapse
daviddalbusco profile image
David Dal Busco

Generally speaking I would say no but, over-engineering is maybe also a matter of perspective?

What I see as over-engineered may not see by others as over-engineered or the contrary, you know what I mean?

⭐️⭐️⭐️ Out of topic ⭐️⭐️⭐️

@mazda excellent choice of cover image 👍

The Wenger Swiss pocket knives were produced in my home region. They still manufacture knives but, have been incorporated in a bigger brand years ago (10 or 20 maybe).

This cover image is almost of a piece of history of local engineering, it makes my day 😃.

Collapse
madza profile image
Madza Author

Switzerland is the first thing that comes to my mind when I see or hear something about them 😉👍 Same about watches and banks 😀😀

Collapse
ppbitb profile image
ppbitb

The inner desire for future-proofing, perfectionism is there. I get it out of my system on personal side projects. Professionally, I am quite extreme in simplifying, doing what's good enough until I have proof that I need more.

Collapse
nabsul profile image
Nabeel Sulieman

I do the same thing.

Collapse
madza profile image
Madza Author

How long did it take for you to develop that skill? And did you learn the hard way by overengineering at the beginning, as well? 👀

Collapse
ppbitb profile image
ppbitb

Like any skills, it was probably gradual and my managers and mentors had probably tried to teach it to me for a long time.
But I remember ~8 years into my career I was working for a very small consultancy (which as opposed to product companies often have widely different deliverables for different clients/projects) company, and our roadmap was just packed full and we were really overbooked.
Our VP of Engineering was a master at juggling and making seemingly impossible amount of work fit, and under her guidance I learned to do the MVP and release.
So I would say, real-life constraints really helped learning the skill.
I now work for another type of business and schedules are comparatively much more comfortable, and I am trying to unlearn this extreme survival focus to allow for more balance, worthwhile tech investments without falling back into over-engineering.
Did I learn the hard way: yes, I would say I learn most things the hard way. It's not that big of a deal if the professional culture allows for learning and failures (which it should) and has fast iteration cycles.

Collapse
tamimi profile image
Tim

For the most part, I only over-engineer the model layer of my applications, largely because I'm worried about future-proofing.

The reason I find myself more anxious about M than V and C, is that you can re-write an API/controllers, or re-develop your front-end at any time, but if you try to mess with the data models in a data-driven application in production you'll probably have a rather bad time.

Collapse
madza profile image
Madza Author

I guess this comes from your personal experience in past, when not putting enough effort into the model layer caused you headaches later on!? 😉

Collapse
thomasthespacefox profile image
Thomas Leathers

SBTCVM, my balanced ternary (base 3) virtual machine, in its prototype codebsse, had a GUI 'launcher' that in a weekend got virtual 'windows' in 90s sim game style...

Eventually, i did end up writing a python/pygame framework, StrazoloidWM, to do the same thing... the framework ended up a LOT less complicated as well... ive used it in a gopberspace client: Zoxenpher, which comes complete with a retro 'desktop' look.

So ironically, even that launcher feature born out of overengineering, was in itself WAY more complex than it had to be...

Oh yea, that launcher, and several other GUI tools that SBTCVM's prototype codebase eventually got, had an entire theming system... that, however, never led anywhere other than: 'not doing that again...' :p

So yes, i have put myself in more than a few situations, where my code complexity blew up in my face... XD

Collapse
madza profile image
Madza Author

Hahah, thanks for sharing 😀😀

Collapse
tvanderb profile image
Talon Vanderbeken

Oh, certainly. When I’m making something that should take around five hours or so I almost all ways find myself re-inventing the wheel to make things overly efficient and organized. Which then ends up taking me 15 hours.

Collapse
madza profile image
Madza Author

I knew I was not the only one 😀😀

Collapse
yo profile image
Yo

Yes 100% I love to over-engineer to learn stuff how it works 😅

Example: In my project, I don't need Memcached to cache the queries we can achieve it only with Redis, but I love to Install Memcached and compare which one is fast 🤣

PS: All happens in production servers 👀

Collapse
madza profile image
Madza Author

There is a bright side to the coin as well 👍💯

Collapse
amurobosetti profile image
Mauro Bosetti

I usually try not to, using TDD (Test-Driven Development) in order to code the smallest, simplest solution that solves the problem, and then refactoring from there to improve the code. Ofc, it's not that simple, but if you extend the idea from just the code to the whole project, it's easier to end up with just the right solution, not too big but also not too small

Collapse
madza profile image
Madza Author

I have also learned the hard way that 'simple' is not 'easy' 😉

Collapse
funbeedev profile image
Fum

For my job, no not really since there's always tight deadlines. But for my personal projects, definitely! It really takes some will power for me not to over spec applications I work on and to eventually decide when its 'complete'.

Collapse
madza profile image
Madza Author

Set tight deadlines for your personal projects, as well 😀😀 But then again, you remember the only person responsible is you and you overengineer anyway 😀

Collapse
hunterpp profile image
Hunter Peress

I think everyone has. I definitely am guilty. I feel it was not until I decided to take a shot at doing my own startups full time, in 2009 did I realize how much time I was wasting on overengineering vs good enough and still be elegant.

Collapse
madza profile image
Madza Author

overengineering vs good enough

I feel it takes skill to differentiate these two, which only comes by experience once you have gone through it, like you said 😉

Collapse
jfbrennan profile image
Jordan Brennan

I think it comes from inexperience or it’s a personal trait - those are the two types of people I see do it.

I’m on the other end. I sometimes start by reducing a solution too much and have to add a little more sophistication. Adding to software tends to be a better proposition than removing, so I like my approach.

Collapse
madza profile image
Madza Author

This is exactly 💯 how I feel! 😉
Very well put! 👍

Collapse
patarapolw profile image
Pacharapol Withayasakpunt

It is hard to say. More of violating the YAGNI.

Also sometimes, rewriting the code for nothing, or creating a new repo for nothing.

Collapse
tomavelev profile image
Toma

Is the software into the hands of a lot of users, does the servicing side have multiple developers. If some of this is true, over engineering may be good. Otherwise is bad...

Collapse
kalashin1 profile image
Kinanee Samson

Right now I have a code I'm working on, I think my first solution is too crude so I want something more elegant, right now I think ave shot myself in the foot.

Collapse
madza profile image
Madza Author

Don't worry 😉You are not the only one 😀😀

Collapse
scrabill profile image
Shannon Crabill

Oof, I'm in this title and I don't like it.

I for sure shoot too high on the first go. I need to be better about focusing small, getting something working then adding onto it later.

Collapse
swatibabber profile image
swatiBabber

I do that a lot, end up being confused with a lot of open ends , with no solution in hand . Gives a lot of learning but delays the task in hand .