Comment by jimkleiber | Hacker News Reader

Comment by jimkleiber | Hacker News Reader

> Instead of a tool shaped specifically for their needs, the framework's core developers often wanted flexibility: they dreamt of open sourcing their framework and it growing popular, so it needed to handle as many cases as possible to reach as wide an audience as possible.

This helped to clarify so much for me. I have done this so frequently not just with software that I've built, but websites, products, even romantic relationships. I can start to imagine different cases (and edge cases) and then eventually get stuck in an infinite loop trying to make it work for everyone.

One of the latest examples: trying to price a SaaS or ebook for friends/customers across different geographies and economic classes.

After reading this post, I felt relieved, maybe because of this line:

> So I started to prefer opinion-driven design when I realised that flexibility comes with a price that is often not worth paying.

Helped me realize just how much energy I've spent trying to keep options open.

Sure. The only way to create quality software at a reasonable cost is to start out solving a really small, specific use case, get that implementation robust, performant, and with few defects. Then expand into another small, specific use case.

This was known already by the pioneering software engineers in the 1960's. There are two things pulling us away from it:

- Business naturally wants to tick off as many boxes as possible on a feature list. This leads to software that purports to do many things, but do them all quite shittily. Like Deming, I believe this is a swindle to acquire many customers in the short term, but screwing them over and losing them long-term.

- There's some sense in trying to generalise the code, too: sometimes that leads to cleaner and more readable code. Often more easily testable code. Well, maybe. It's a very difficult point of judgment, and I personally get it wrong quite often.

Those small things need to communicate with each other at some point, so you build stuff around them. You end up with the same complexity regardless, just organized differently.

Now, I don’t disagree with you. Maybe this organization is very beneficial. Typically systems with small, specific pieces that talk over a generic, well designed interface do work well. HTTP, Unix Pipes, currency, mail, bees... the whole becomes adaptive and accommodating.

This kind of design is discussed in the latter half of Elements of Clojure by Zachary Tellman.

https://elementsofclojure.com/

What I like about this, to come back to the article, is that it gives a clear sense of where generality should reside.

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system."

https://en.wikiquote.org/wiki/John_Gall

I’ve always wondered if it has something to do with the software building process in general. First you get burned a few times because you overlook edge cases. As your skills improve, you get better at anticipating these problems. But then you reach a point where it goes overboard. You start seeing ghosts that aren’t there and solving problems that don’t exist. The mindset that helped you improve as a developer eventually makes you over think things and you need to go back to focusing on solving specific problems.

YAGNI, basically.

What's ironic about it is that about 1/2 the time developers correctly anticipate the general shape of the upcoming problem but it comes in a way they didn't expect thus they'd have done better by assuming it was never going to happen and dealing with it when it does.

This is a subtle distinction most people don't get.

I don't view it as a software development issue per se. Humans are just bad at predicting the future, bad at knowing how bad we are and bad at recognizing when we've been bad at it.

Trying to build a REST API coz the customer will definitely want it some day and thinking you've got a system at the slots in Vegas are two sides of the same coin.

And, I've learned the hard way that if a developer has got the same confidence that a granny at the slot machines has, preaching YAGNI isnt going to convince them they're wrong.

Week late but I was just looking at my comments saw this and it’s so spot on. Attempting to predict the future is a suckers game.

It applies to all layers of software engineering as well. Yesterday I was writing an XML parser (on top of Go's std lib), but I needed to read the first line of the XML file to determine if it was UTF-8 or ISO encoded.

I added code and lines to handle edge cases - what if the XML prolog is not on the first line? What if it starts with whitespace?

But these are all edge cases that are unlikely to happen, and if they do... just let my application crash or error, it's not worth adding code until it's actually needed.

Same with performance, I'm thinking "I should add caching", but I don't even know how efficient my application is if it has to read & parse the files for every request - I'm assuming fast enough, until proven otherwise.

My grandfather invested in a new apartment building back in the 50s. At the end of every day he'd go there with a case of beer for the construction workers. He said, "I want to make sure they care. So if they see a place where one nail is enough, they'll hammer in two nails just to be sure."

That's how I feel for my clients; I hammer in all the nails I can think of. The result is, usually I'm shocked by how few bugs there are in production. I've had business software running 24/7 that goes for years without any intervention. The occasional upgrade or minor UI fix. Error-proofing is the state of mind you're in when you write that parser and google for every edge case you can think of.

[edit] I just want to add another thought. There's such a thing as needing to ship. If you add every bell and whistle, every speed improvement and cache, you'll just keep going and never finish. The important thing is to think about these possibilities as you're writing the code, and document them so you know where the pain points might be if this software is still running much more intensively ten years down the road.

Great story. I think it is about a different problem that what the post is about though. The post is about yagni and not adding unneeded configuration and complexity, and having an opinionated design instead. I think you story is more about solving the actual real problem for the end user well.

Hm. Thank you. And good point. Designing for other coders to work with your code is very different than designing for only a client, and your future self. Too many options or unnecessary hooks in an API is a pain when you just want to do something clear with it. Not enough options can render a platform unsuitable. In some ways this is a classic problem - if you run a shoe store, do you put out one beautiful shoe that everyone tries to fit into, or too many shoes to choose from. But in software, the feet change shape. So the more opinionated something is, the more it runs up against an unforeseen future (I'm thinking about Actionscript, JQuery, D3...) Maybe a good balance would be to design an opinion into the software, but with alternate futures in mind, to try to foresee breaking changes... this can be opinionated, but still leave options open in case requirements change..? But yes, it's harder if you're building an ecosystem.

TL;DR I still think writing more options is better as a rigorous thought process, if not as actual code. If you must, hide them from the API consumer, but have them in the arsenal. (In itself, that's an opinion).

Why spend 3 minutes making your code correct when you can just spend a day or two understanding and debugging user bug reports? (That is, if you have only a few users.)

This insight is one of the motivations for "convention over configuration."

Reply on news.ycombinator.com