3 ms·

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 compl

• noduerme 5y ago
  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).