4 ms·

YAGNI only applies for a "top-level" applications. For libraries used by third parties (e.g. the standard library of a language) you want clients do be able to

by goto11 5y ago

YAGNI only applies for a "top-level" applications. For libraries used by third parties (e.g. the standard library of a language) you want clients do be able to do things you haven't imagined, so different trade-off are in place. For software which cant easily be updated, like mars rover software, you also have to prepare for all eventualities up front. I don't agree with the article that you should always select a relational database up front. Should Calculator really use a relational database to persist configurations? This is exactly where YAGNI applies.

Jtsummers 5y ago
> By this I mean, if you need a database at all, you should jump to having a relational one straight away, and default to a relational schema, even if your earliest set of requirements could be served by a “document database” or some basic flat-file system. Emphasis added. So the author probably agrees with you that a calculator doesn’t need a database.
- tonyarkles 5y ago
  I’m laughing a bit at the calculator example though because, in 2021, if the calculator started to be configurable from within the UI out have any kind of persistence (eg keeping your calculation history from session to session) my very first inclination would be to grab SQLite and skip right past plain text/YAML/.ini etc files.
- goto11 5y ago
  The calculator on Windows does persist a few settings, for example windows size and whether "scientific" or "standard" mode is selected. This could be saved in a config file or some other storage format. Windows has a simple per-application key-value store for such settings. A relational database would be overkill and increase overall complexity.
squiggleblaz 5y ago
> I don't agree with the article that you should always select a relational database up front. Should Calculator really use a relational database to persist configurations? This is exactly where YAGNI applies. I don't think this is where yagni applies at all. Either way, if you want to start storing data, you will need to evaluate it. Yagni stops us from saying "but what if, but what if, but what if!" To decide whether we should allow storage to be a yagni exception, we need to look at what we do first. So the question is, how often are we writing Calculator, and how often are we writing an app to help organise a business? I think the balance is on the latter side. So when we're trying to decide how to store our data, if we have strong reasons to prefer a simple text file, then we should. But by default, we should go for sqlite or something bigger.
- goto11 5y ago
  > if we have strong reasons to prefer a simple text file, then we should. But by default, we should go for sqlite or something bigger. That seems like the opposite of the YAGNI principle though.
drewcoo 5y ago
No, libraries are not exempt and should not be gold plated. The Mars rover does not need a kitchen sink just in case. YAGNI, KISS, the parsimony principle, the Unix way, DRY, and many others are all universal reminders to not build bloated, overengineered crap.
- goto11 5y ago
  YAGNI is is also postponing abstractions, flexibility and extension points until the application requires it. But for a library you need to design the abstractions up front because you don't know the requirements of the users, and it is difficult to change later.

by goto11 5y ago

Jtsummers 5y ago

> By this I mean, if you need a database at all, you should jump to having a relational one straight away, and default to a relational schema, even if your earliest set of requirements could be served by a “document database” or some basic flat-file system. Emphasis added. So the author probably agrees with you that a calculator doesn’t need a database.

tonyarkles 5y ago
I’m laughing a bit at the calculator example though because, in 2021, if the calculator started to be configurable from within the UI out have any kind of persistence (eg keeping your calculation history from session to session) my very first inclination would be to grab SQLite and skip right past plain text/YAML/.ini etc files.
goto11 5y ago
The calculator on Windows does persist a few settings, for example windows size and whether "scientific" or "standard" mode is selected. This could be saved in a config file or some other storage format. Windows has a simple per-application key-value store for such settings. A relational database would be overkill and increase overall complexity.

squiggleblaz 5y ago

> I don't agree with the article that you should always select a relational database up front. Should Calculator really use a relational database to persist configurations? This is exactly where YAGNI applies. I don't think this is where yagni applies at all. Either way, if you want to start storing data, you will need to evaluate it. Yagni stops us from saying "but what if, but what if, but what if!" To decide whether we should allow storage to be a yagni exception, we need to look at what we do first. So the question is, how often are we writing Calculator, and how often are we writing an app to help organise a business? I think the balance is on the latter side. So when we're trying to decide how to store our data, if we have strong reasons to prefer a simple text file, then we should. But by default, we should go for sqlite or something bigger.

goto11 5y ago
> if we have strong reasons to prefer a simple text file, then we should. But by default, we should go for sqlite or something bigger. That seems like the opposite of the YAGNI principle though.

drewcoo 5y ago

No, libraries are not exempt and should not be gold plated. The Mars rover does not need a kitchen sink just in case. YAGNI, KISS, the parsimony principle, the Unix way, DRY, and many others are all universal reminders to not build bloated, overengineered crap.

goto11 5y ago
YAGNI is is also postponing abstractions, flexibility and extension points until the application requires it. But for a library you need to design the abstractions up front because you don't know the requirements of the users, and it is difficult to change later.