>I can give you an abundance of examples. We were creating a page that was going to use state in a certain way. I was trying to insist that we address the way state will be handled across pages ahead of time. These concerns were dismissed as premature optimization. A few months later we had 5 pages with the state being handled in 5 different ways.
The right time to address this was probably a bit at a time after the 1st, 2nd and 3rd pages. Certainly not before the 1st and definitely not after the 5th.
>All of that could have been avoided by spending 1 day thinking a little harder and planning for the future.
The reason why you try as hard as possible to avoid planning for the future is because it's really hard to predict the future. Moreover humans have an inbuilt bias towards thinking we are better than we are at it (hence the gambling industry).
Refactoring as soon as possible after the fact will always produce better designs than up front planning for this reason.
>there are regular ways that programs grow based on how the business is growing and you can predict certain places
This is the kind of phrase that makes alarm bells go off in my head that somebody SHOULD be following YAGNI and isnt.
If it's defaults in a well worn framework that doesnt railroad you then fine but anything more than that - red flags all around.
Rule of 3 is often correct, first time just do it, second consider if it'll very likely happen a third time and when the third time happens it's darn well time to do it!
HOWEVER, this only works if you have the agency at an organization to allocate time for doing something. Contrary to this when you are in an organization of management that doesn't understand technical debt (or is fine with it because it just means more consulting hours) then it's absolutely the correct choice to stall and/or fix things "prematurely" (iff you can see what product they are trying to create without knowing it) if you'll be holding the shit-can of duplicated crap down the line getting knuckled because things aren't going fast enough due to technical debt.
The right time to address this was probably a bit at a time after the 1st, 2nd and 3rd pages. Certainly not before the 1st and definitely not after the 5th.
>All of that could have been avoided by spending 1 day thinking a little harder and planning for the future.
The reason why you try as hard as possible to avoid planning for the future is because it's really hard to predict the future. Moreover humans have an inbuilt bias towards thinking we are better than we are at it (hence the gambling industry).
Refactoring as soon as possible after the fact will always produce better designs than up front planning for this reason.
>there are regular ways that programs grow based on how the business is growing and you can predict certain places
This is the kind of phrase that makes alarm bells go off in my head that somebody SHOULD be following YAGNI and isnt.
If it's defaults in a well worn framework that doesnt railroad you then fine but anything more than that - red flags all around.