undefined | Better HN

0 pointstinco4y ago0 comments

It annoys me so much that after honing my skill as an engineer for 15 years now I still fall into the trap of not enough YAGNI thinking. There's a precarious middle ground there for sure. Even though I still fall into the trap of over designing, I believe it's way worse than under designing. I don't remember a single instance where a 'YAGNI' under designing cost us much except designing and implementing the feature the right way, a cost which we'd incur anyway. In contrast I've caused my team to work with an overly complex codebase for years on multiple occasions.

0 comments

eternityforest4y ago

The only time I've regretted overdesigning is when there's been significant original design work involved.

I don't think I've ever regretted overdesigning to meet a common standard or match how everyone else does something.

A lot of the YAGNI I see is in the form of "We don't need a framework, just do vanilla JS" or "I only need one of the features of this library, I'll just write it myself".

Almost all of my own big tech regrets have to do with building something "innovative". Even when they've solved the problem better than existing solutions they often become regrets, just for the simple fact that they aren't better by enough to justify the nonstandardness.

tincoOP4y ago

Ah, I think I wouldn't qualify those as YAGNI decisions, more in the premature optimisation direction. YAGNI is preparing for future integrations that might never happen, or preparing for supporting multiple databases, special users, special circumstances. It is always a decision of doing more work now, versus more work later.

The decision to not use a framework or a library is sort of the reverse in that you're making a decision that you can later reverse by reducing the complexity of your own code.

Definitely agree with you that a part of being a very effective development team is owning as little code as possible, by using as many existing solutions as possible.

ziml774y ago

YAGNI is difficult to get right because we can't see into the future. There's certainly been plenty of times where it would have been great if something was designed from the start with the new functionality in mind instead of having to hack it in. But there's also many times where thinking that we would need something that we didn't created maintenance and performance overhead.

j / k navigate · click thread line to collapse