4 ms·

This misses the point that overengineering takes longer to do, so it adds costs to the initial development process. Unsurprisingly there’s less cost later - you

This misses the point that overengineering takes longer to do, so it adds costs to the initial development process. Unsurprisingly there’s less cost later - you’ve already paid a lot of it!

Dobiasd 5y ago
You're absolutely right, of course. :) While this was not the point of this article, I just added a remark about this important fact nonetheless: https://github.com/Dobiasd/articles/commit/2a251204183cb45e798627ea27b8471e1ae6bfe1 https://github.com/Dobiasd/articles/commit/2a251204183cb45e7... Thanks!
jrodthree24 5y ago
This pretty much just comes down to estimate how much you're going to need and then go for that in the first place. Which I imagine is what people would be aiming for anyway? I don't think anyone is using YAGNI knowing they are in fact going to need it.
- ghiculescu 5y ago
  The other issue is most engineers want to over-engineer. So anything that encourages that without noting the real costs should probably be tampered down.
  - justicezyx 5y ago
    > The other issue is most engineers want to over-engineer. My experience is that everyone wants to engineer to their own standards. When it's in a team setting, people with different standards (and tastes) results into "over-engineered" code base.
ellen364 5y ago
That seems like the best case scenario — the over-engineering is costly upfront and worth it later on. But if there’s a problem in the over-engineering, e.g. mistaken assumptions, fixing it is another round of expense. So over-engineering is “expensive now and hopefully cheap later”, while under-engineering is “cheap now and maybe expensive later”. In one scenario you get 1-2 rounds of expensive. In the other you only get 0-1 rounds of expensive. With that in mind, under-engineering the first implementation might be the sensible default choice.

4 ms·

This misses the point that overengineering takes longer to do, so it adds costs to the initial development process. Unsurprisingly there’s less cost later - you

by ghiculescu 5y ago

This misses the point that overengineering takes longer to do, so it adds costs to the initial development process. Unsurprisingly there’s less cost later - you’ve already paid a lot of it!

Dobiasd 5y ago
You're absolutely right, of course. :) While this was not the point of this article, I just added a remark about this important fact nonetheless: https://github.com/Dobiasd/articles/commit/2a251204183cb45e798627ea27b8471e1ae6bfe1 https://github.com/Dobiasd/articles/commit/2a251204183cb45e7... Thanks!
jrodthree24 5y ago
This pretty much just comes down to estimate how much you're going to need and then go for that in the first place. Which I imagine is what people would be aiming for anyway? I don't think anyone is using YAGNI knowing they are in fact going to need it.
- ghiculescu 5y ago
  The other issue is most engineers want to over-engineer. So anything that encourages that without noting the real costs should probably be tampered down.
  - justicezyx 5y ago
    > The other issue is most engineers want to over-engineer. My experience is that everyone wants to engineer to their own standards. When it's in a team setting, people with different standards (and tastes) results into "over-engineered" code base.
ellen364 5y ago
That seems like the best case scenario — the over-engineering is costly upfront and worth it later on. But if there’s a problem in the over-engineering, e.g. mistaken assumptions, fixing it is another round of expense. So over-engineering is “expensive now and hopefully cheap later”, while under-engineering is “cheap now and maybe expensive later”. In one scenario you get 1-2 rounds of expensive. In the other you only get 0-1 rounds of expensive. With that in mind, under-engineering the first implementation might be the sensible default choice.