3 ms·

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

by 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.

by lbarrow 13y ago

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.