Hacker News Reader

Comment by a_wild_dandan | Hacker News Reader

I see so many HN comments endorsing "build the product to exact specification using the minimum reasonable tool set." When you then ask "what happens when the specification changes?" you get hilarious answers like "just say no to the user", or "just extend the app!"

This is why I always over engineer a bit, especially on new projects. I'll happily, for instance, add a framework before it's strictly necessary. I've never regretted that decision in the end.

If people here want to use a 5 gallon bucket on an initial 5 gallon job, go for it. Best of luck to you. I'll be over here starting with a 10 gallon bucket and not sweating when the customer needs to add another gallon...

View on HN

One of the things that I've learnt is that the world isn't clear-cut enough for YAGNI[1] all the time, and that it's usually worth building things slightly more generic/flexible than the original ask, because it's rare that the original requestor understood the problem enough first time round.

[1] https://martinfowler.com/bliki/Yagni.html

There are so many automated safe refactore and build time safeguards you can do with statically typed language, I’m much more comfortable making major changes and extension with Typescript than vanilla JS.

The problem with overengineering is that you don’t have a good grasp on a generalized architecture until you have two or three use cases. Of course anything dealing with cross cutting concerns like logging and authentication it’s easier to add up front.

I don’t know any modern front end frameworks, but when working within a team, I’m all for opinionated popular frameworks. It’s s lot easier to onboard people and from a completely selfish standpoint, developers who are concerned with their careers want to be able to put a transferable toolset on their resume.

It’s rare that I find a comment which validates my own practices like this. I personally love creating systems and abstractions, and admittedly I will sometimes create one when a simpler solution would suffice. However those “over-engineered” solutions have frequently saved me lots of time much later when business requirements change.

Your stance sounds different to the grandparent's.

There's a world of difference between adding a framework and over-engineering something that could have used a simpler solution.

My experience has been the exact opposite of yours, whenever I added something complicated, it either never got used and unnecessarily complicated the code, or when the time came to use the fandangled cleverness I lovingly wrought, it never quite met the need I actually ended up having.

So I stopped doing that years ago and now always write the simplest code. Never regretted it. I will add frameworks early though.

That is an excellent approach for new projects. On stable projects it's pretty common to have lots of little "special" bits where someone over-designed and created an unholy mess. (I'm guilty of this as well, of course.) In stable systems simple is almost always best.

I think it depends on what you're engineering. For example, adding static typing to a language has immediate gains regardless of code base size. It is also low risk and easy to implement.

Designing a spring quartz scheduler backed by a DB when a simple cron job would do? That's overkill.

There’s a difference between an extra layer of abstraction/indirection and going crazy with the a bunch of new hot (unnecessary/inapplicable) technology.

Now the non-strawman version: it's a 5 gallon job, vanilla React.js is already a 10 gallon bucket, and typescript comes in buckets up to 100 gallons.

It's often a matter of how much you think the job is likely to expand, how much you should frontload work to make that simple.

Reply on news.ycombinator.com