I've built a replica of Golden Gate using planks, nails and clothesline.

Some people said I should use steel and concrete support, but my answer to them was YAGNI. Grand opening should be any day now, we expect at least 10,000 cars the first day.

Know thy context. Sometimes YAGNI - but make sure YAGNI out of experience, not ignorance.

Quote:
Sure poorly coded and complete is great but poorly coded hardly ever makes it to complete.

Sure it does. Just redefine "complete" and ship it. You can always patch it later, right? :D

As I think others are saying, isn't the problem that by asking, "Where does YAGNI end?", one is assuming that that's the only advice one should follow? Isn't there another rule, zero-one-infinity? The two rules agree if you need zero or one, but, if you need two, YAGNI says you don't need infinity while zero-one-infinity says you do. Maybe one place YAGNI ends is where zero-one-infinity begins? Maybe YAGNI needs to be used alongside "make if work, make it right, make it fast"?

If you only have one damage type while you're coding, there's no sense trying to add in the ability to use other damage types even if you suspect that it's very likely the end product will have more than one damage type. It's not entirely because "very likely" doesn't mean "it is most certainly so", but also because you don't know what sort of framework will be required to support the new damage types. In other words, you're writing code based on assumptions about your assumptions. So, not only are you making the code more complicated in the short term, the chances that it'll pay off in the long run aren't necessarily very good, and the time you spent making your life harder by adding complications could be spent on making other parts work/right/fast.

Quote:Original post by linternet
Refactoring working code takes time that could be used for putting additional features in. It could end up saving time or you could be far enough along that hacking is the fastest way to finish. I don't have a foolproof formula to tell the difference.

I suspect most people underestimate the benefit/cost ratio. I'm pretty aggressive about it. Some justification.

Quote:Original post by Zahlman
I suspect most people underestimate the benefit/cost ratio. I'm pretty aggressive about it. Some justification.

You're probably right and if I were perfect at assessing the benefit/cost ratio I wouldn't need to have this discussion :).

I'd also say it's likely that the more aggressive a programmer is about refactoring, the more skill he or she has (as it's easier for them to refactor and, hence, takes less time).

Additionally, a primary goal of many independent game projects is to learn (learning is, of course, a non-trivial goal of virtually any project), which makes aggressive refactoring desirable as, even if it takes you forever to refactor, you'll improve your programming skills and it'll be easier the next time around.

With regard to a specific project, however, if the goal is to complete it as quickly as possible, then the benefit/cost raito changes substantially depending on the programmer (what's quick and easy for you to refactor may be time consuming and difficult for me) and the deadlines.

Quote:Original post by linternetWith regard to a specific project, however, if the goal is to complete it as quickly as possible, then the benefit/cost raito changes substantially depending on the programmer (what's quick and easy for you to refactor may be time consuming and difficult for me) and the deadlines.

Will there ever be a project that will not need to be completed ASAP?

This is the true challenge here. Many industries are very hostile towards innovation and change for this very reason. Both of them reduce current effectiveness.

Again, it depends. For some industries, this may spell doom. For others, it may be the only way to function.

But no matter how much tradition is respected, a healthy dose of openess to new concepts and allocating time for them is simply mandatory. In IT, things just move 100 times faster than anywhere else.

Quote:Original post by Way Walker
As I think others are saying, isn't the problem that by asking, "Where does YAGNI end?", one is assuming that that's the only advice one should follow? Isn't there another rule, zero-one-infinity? The two rules agree if you need zero or one, but, if you need two, YAGNI says you don't need infinity while zero-one-infinity says you do. Maybe one place YAGNI ends is where zero-one-infinity begins? Maybe YAGNI needs to be used alongside "make if work, make it right, make it fast"?

If you only have one damage type while you're coding, there's no sense trying to add in the ability to use other damage types even if you suspect that it's very likely the end product will have more than one damage type. It's not entirely because "very likely" doesn't mean "it is most certainly so", but also because you don't know what sort of framework will be required to support the new damage types. In other words, you're writing code based on assumptions about your assumptions. So, not only are you making the code more complicated in the short term, the chances that it'll pay off in the long run aren't necessarily very good, and the time you spent making your life harder by adding complications could be spent on making other parts work/right/fast.

To directly answer the question it stops when you use it to justify poor code. Good code tries to be flexible while being simple, non YAGNI code builds fluff just in case it is necessary. Bad code is brittle and resists change. YAGNI doesn't defend bad code. Another rule that trumps YAGNI in the original setting is DRY(Don't Repeat Yourself)( that switch is ripe to be repeated all over the place such as a def atk max health calc.s). For the OP at this point I would let it go for now. If it causes problems later fix it later, and that is YAGNI for you.

Quote:Original post by Antheus

Quote:Original post by linternetWith regard to a specific project, however, if the goal is to complete it as quickly as possible, then the benefit/cost raito changes substantially depending on the programmer (what's quick and easy for you to refactor may be time consuming and difficult for me) and the deadlines.

Will there ever be a project that will not need to be completed ASAP?

Yes. If you are integrating with other software it may not be beneficial to finish early. But in any case, it's the architect's job to push against pressure from management in the early stages.