5 ms·

This is superb. YAGNI may have it's own Wikipedia entry, but that doesn't mean that we remember it when a brilliant idea comes to mind. https://en.wikipedia.or

This is superb. YAGNI may have it's own Wikipedia entry, but that doesn't mean that we remember it when a brilliant idea comes to mind. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

senatorobama 9y ago
All hail YAGNI, the god of code.
- fiddlerwoaroof 9y ago
  I find that YAGNI is usually used to justify hacking something together without thinking about the design of the system you’re working on.
  - syllogism 9y ago
    Yagni is a duality though (like a trinity, but two). You've just met Yagni's other face, You Are Going To Need It.
    - TylerE 9y ago
      An important corollary to this is "0, 1, many". Any time you are storing data, the acceptable number of items to handle are none, exactly one, or a number limited only by machine resources. Don't design a container to hold, say, up to 5 items.
      - always_good 9y ago
        I don't understand. I would just about never want to use an unbounded buffer, for example, for a channel.
        ComputerGuru 9y ago
        Yes but that is an artificial limit and not an architectural limitation. i.e. a feature added to code that was once / would have been infinite otherwise.
      - 0xcde4c3db 9y ago
        On the other hand, instantiating/specializing a container to hold up to 5 items can be a perfectly reasonable thing to do, depending on the application. It might be a design requirement that a safety-critical program never has to restart due to heap fragmentation, for instance.
  - newfoundglory 9y ago
    You sound lucky, not to have tried arguing someone down from building a platform that would be able to implement both the system you're working on and any related hypothetical future systems as well.
  - draw_down 9y ago
    I wish I felt that way. I’ve seen so much silly overcomplicated junk in my career, my inclination is always to keep it extremely simple.
- nurettin 9y ago
  In the beginning, KISS and YAGNI created DRY, but it was corrupted and gave birth to DIY and NIH.

senatorobama 9y ago

All hail YAGNI, the god of code.

fiddlerwoaroof 9y ago
I find that YAGNI is usually used to justify hacking something together without thinking about the design of the system you’re working on.
- syllogism 9y ago
  Yagni is a duality though (like a trinity, but two). You've just met Yagni's other face, You Are Going To Need It.
  - TylerE 9y ago
    An important corollary to this is "0, 1, many". Any time you are storing data, the acceptable number of items to handle are none, exactly one, or a number limited only by machine resources. Don't design a container to hold, say, up to 5 items.
    - always_good 9y ago
      I don't understand. I would just about never want to use an unbounded buffer, for example, for a channel.
      - ComputerGuru 9y ago
        Yes but that is an artificial limit and not an architectural limitation. i.e. a feature added to code that was once / would have been infinite otherwise.
    - 0xcde4c3db 9y ago
      On the other hand, instantiating/specializing a container to hold up to 5 items can be a perfectly reasonable thing to do, depending on the application. It might be a design requirement that a safety-critical program never has to restart due to heap fragmentation, for instance.
- newfoundglory 9y ago
  You sound lucky, not to have tried arguing someone down from building a platform that would be able to implement both the system you're working on and any related hypothetical future systems as well.
- draw_down 9y ago
  I wish I felt that way. I’ve seen so much silly overcomplicated junk in my career, my inclination is always to keep it extremely simple.
nurettin 9y ago
In the beginning, KISS and YAGNI created DRY, but it was corrupted and gave birth to DIY and NIH.