3 ms·

I chose that example precisely because it makes sense to have a Pet class that holds common code between Dogs, Cats and Chickens. When the code only contains Do

by lbarrow 13y ago

I chose that example precisely because it makes sense to have a Pet class that holds common code between Dogs, Cats and Chickens. When the code only contains Dogs, though, the Pet class is unnecessary, even if you plan to introduce Cats at a later date.

angersock 13y ago
But you knew right then that you were going to implement the other two classes, and that you would need the code. It's not like you aimlessly added abstraction to cover your lack of design and grasp of the problem space--you had done some back of the envelope design and knew you needed it. That's not premature at all.
- lbarrow 13y ago
  Your code shouldn't be designed to reflect what you believe is going to happen to the program eventually; it should be designed to fit the requirements as they are right now. If a Pet class makes sense later on, add it later on.
  - angersock 13y ago
    The example stated "when we add chickens and cats", not "if we decide to add chickens and cats". It was clear that the requirements at the time included 3 types of animals--if it wasn't clear, you should've written the spec better. Look, I'm on your side about YAGNI and shipping products not code and whatever other stuff we probably both genuflect at. I'm actually dealing right now with a lot of fallout involving overengineering a project when it should just be kicked out the door and set to work. That all said, too much shoddy engineering and cowboy-coding is done with YAGNI given as a hollow excuse. There is a lot of pushback on doing upfront design work, but even a cursory consideration of the problem domain and code structure will oftentimes yield better code that otherwise would've been ignored under the banner of "we aren't gonna need it". EDIT: Hell, I'll take it one step further: when developers do decide to be lazy and claim YAGNI, they often aren't lazy enough, and instead write hacks that are too large to just get something done. If you are going to half-ass something, by God, half-ass it all the way.
    - shawnz 13y ago
      > if it wasn't clear, you should've written the spec better. This is basically a spec-writing problem in the first place, not a code problem. OP is wearing the spec-writing hat and the coding hat at the same time. But it doesn't change the question at hand. Should the spec for 1.0 include hooks and scars for features you expect to be in 2.0, or should you wait until it is confirmed with 100% certainty that they will exist?
    - vidarh 13y ago
      If I had a dollar for every time clients have said "when we X" and then later went on to insist we need to do Y instead, that is completely opposite to X, and counter to everything agreed in specs, I'd be happily retired by now, living off my fortune. It'd be great if we could all know in advance what the requirements will actually be, but that requires us to be able to visualize exactly how everything will actually work in advance. That is rarely the case. YAGNI is not about avoiding design (though I agree it might be used as an excuse), but about deferring decisions that does not need to be locked in yet, until they need to be. That does not mean you should not design. Just don't go into unnecessary levels of details, and iterate when more detail is needed.
- vidarh 13y ago
  A lot of the time when people say the know, they only think they know. And even if they do know, chances are they don't know how they will do it, and so which functionality will actually be shared. Even if you insist it isn't premature, the question I'd ask is: for what purpose are you adding it? If not code currently needs it, it's just extra complexity at this point taking time away from writing code that is needed right now. Now, if you're going to add the Cat class tomorrow, and it will happen 100% guaranteed unless you get hit by a bus, then sure - that's still in keeping with YAGNI, I'd argue.
andrewvc 13y ago
Plus, the generic behaviors of a Pet (say, life and death), are all logically separate from dog specific things. Even if the world only contains dogs, having a Pet class might lead to more organized code.
Keyframe 13y ago
So what happens down the road when you do need it? Seems to me it violates DRY and borks your serialization for save states. Maybe it's just in this particular example though, or maybe it should be viewed not on a code level but more on a feature set level.
tzs 13y ago
So would your Dog class have both dog stuff (e.g., code that models dog psychology) and game stuff (code to deal with animation loops, collisions, and such)?

by lbarrow 13y ago

angersock 13y ago

But you knew right then that you were going to implement the other two classes, and that you would need the code. It's not like you aimlessly added abstraction to cover your lack of design and grasp of the problem space--you had done some back of the envelope design and knew you needed it. That's not premature at all.

lbarrow 13y ago
Your code shouldn't be designed to reflect what you believe is going to happen to the program eventually; it should be designed to fit the requirements as they are right now. If a Pet class makes sense later on, add it later on.
- angersock 13y ago
  The example stated "when we add chickens and cats", not "if we decide to add chickens and cats". It was clear that the requirements at the time included 3 types of animals--if it wasn't clear, you should've written the spec better. Look, I'm on your side about YAGNI and shipping products not code and whatever other stuff we probably both genuflect at. I'm actually dealing right now with a lot of fallout involving overengineering a project when it should just be kicked out the door and set to work. That all said, too much shoddy engineering and cowboy-coding is done with YAGNI given as a hollow excuse. There is a lot of pushback on doing upfront design work, but even a cursory consideration of the problem domain and code structure will oftentimes yield better code that otherwise would've been ignored under the banner of "we aren't gonna need it". EDIT: Hell, I'll take it one step further: when developers do decide to be lazy and claim YAGNI, they often aren't lazy enough, and instead write hacks that are too large to just get something done. If you are going to half-ass something, by God, half-ass it all the way.
  - shawnz 13y ago
    > if it wasn't clear, you should've written the spec better. This is basically a spec-writing problem in the first place, not a code problem. OP is wearing the spec-writing hat and the coding hat at the same time. But it doesn't change the question at hand. Should the spec for 1.0 include hooks and scars for features you expect to be in 2.0, or should you wait until it is confirmed with 100% certainty that they will exist?
  - vidarh 13y ago
    If I had a dollar for every time clients have said "when we X" and then later went on to insist we need to do Y instead, that is completely opposite to X, and counter to everything agreed in specs, I'd be happily retired by now, living off my fortune. It'd be great if we could all know in advance what the requirements will actually be, but that requires us to be able to visualize exactly how everything will actually work in advance. That is rarely the case. YAGNI is not about avoiding design (though I agree it might be used as an excuse), but about deferring decisions that does not need to be locked in yet, until they need to be. That does not mean you should not design. Just don't go into unnecessary levels of details, and iterate when more detail is needed.
vidarh 13y ago
A lot of the time when people say the know, they only think they know. And even if they do know, chances are they don't know how they will do it, and so which functionality will actually be shared. Even if you insist it isn't premature, the question I'd ask is: for what purpose are you adding it? If not code currently needs it, it's just extra complexity at this point taking time away from writing code that is needed right now. Now, if you're going to add the Cat class tomorrow, and it will happen 100% guaranteed unless you get hit by a bus, then sure - that's still in keeping with YAGNI, I'd argue.

andrewvc 13y ago

Plus, the generic behaviors of a Pet (say, life and death), are all logically separate from dog specific things. Even if the world only contains dogs, having a Pet class might lead to more organized code.

Keyframe 13y ago

So what happens down the road when you do need it? Seems to me it violates DRY and borks your serialization for save states. Maybe it's just in this particular example though, or maybe it should be viewed not on a code level but more on a feature set level.

tzs 13y ago

So would your Dog class have both dog stuff (e.g., code that models dog psychology) and game stuff (code to deal with animation loops, collisions, and such)?