Hacker News Reader

Comment by nerdponx | Hacker News Reader

I've definitely been bitten by designs that were too simple in critical areas. Interfaces can always be added to and code can always be deduplicated later. But an accretion of kludges around an insufficient set of core functionality is absolutely worse than having a little extra functionality that you end up deleting later.

Don't try to solve speculative future problems. But if you are pretty sure you're going to need something in the future, you should probably take it into consideration in your design.

View on HN

Yes, during a rewrite of a product I had a (new) team member scream YAGNI at me with supercilious delight when I pointed out all functions needed to account for the full primary key of (id, territory) rather than just (id) because we will definitely be needing it imminently although the current build only worked with data for one territory.

We then had to spend a long time cleaning up the mess when lo and behold, we needed to add more territories to the dataset.

I think we've swung too far in the wrong direction when it comes to "premature abstraction" and yagni.

The only acceptable reason I've seen for writing bad code is "we might not be here tomorrow" but that is literally only valid for extremely young startups and even then those decisions could ripple and indirectly kill the company in the future when they're no longer able to pay off the tech debt in time

As someone who has been operating in hacky mode for years there's another situation where

> we might not be here tomorrow

Is true and increasingly common which is the recurring rounds of layoffs we all seem to be experiencing. It's in the individual developer's interest to bodge something in if it makes them appear productive in time for the next layoff. Certainly not a healthy incentive for building good software but it is what it is.

If the MBA-management class wanted good software they wouldn't be so short sighted, but it's all about the pump-and-dump right now.

For me database structure should be built with decent flexibility, everything else is easier to refactor in the future when needed and best to keep simple unless it is a pattern you have definite experience with in the past and it is basically no cost and high certainty of working out.

I hear YAGNIs when I know a pattern from experience with past projects even though deep down I know it is not that high effort due to past experience and we will need it.

I hate hearing YAGNIs when it is something I specifically have had experience with in the past and they think it is too complex because they haven't done it.

And they won't get it because they haven't gone through it.

You know, I plainly disallow composed PKs on my workplace just so nobody ever makes that specific argument. Nobody can work with partial keys if your keys all have a single field.

> But an accretion of kludges around an insufficient set of core functionality is absolutely worse than having a little extra functionality that you end up deleting later.

I agree that an accretion of kludges is bad. The problem here comes down to usually the skill of the programmer when the new work comes up. To people who don't understand the code, they are more likely to make what they think is a simple kludge than actually refactor to solve the problem "correctly", which usually involves more thought and creativity.

Whereas extra functionality usually increases the code surface area, and once published as a public interface to a library, is very costly and painful to delete. Then it festers as complications to new code that is added have to assume this extra functionality is used rather than not.

The skill of the programmer is subordinate to getting stuff done at a reasonable velocity.

Given unlimited time, a sufficiently skilled programmer can always refactor as needed, when needed, and not a moment before. Data formats can be migrated, domain primitives can be reconsidered, names can be changed, interface boundaries can be moved.

But there is never unlimited time, Unless you are simply programming for the joy of programming, and not particularly concerned about finishing some thing, or being able to make changes without taking on a large project each time.

YAGNI is a mantra that we use to keep ourselves away from designing too much too early, introducing inappropriate abstractions and complexity that we will come to regret. But we are not religious fundamentalists either. YAGNI is a reminder, not a commandment. Just like DRY has its opposing WET, YAGNI has its opposing principle, even if we don't have a pithy name for it.

> Don't try to solve speculative future problems. But if you are pretty sure you're going to need something in the future, you should probably take it into consideration in your design.

This is the real balance being struck. YAGNI is a pushback against the "you never know, one day we might want to expand this thing. I can't think of why right now, but let's make sure it's easy to do when if it happens!"

That's very different from the case of "There's a use case that we plan on getting to in 3 weeks. Why don't we save ourselves some future work and do this now"

Reply on news.ycombinator.com