4 ms·

> How much software development isn't either implementing the actual features or making the software easier to modify? The key is the adjective, presumptive. Y

> How much software development isn't either implementing the actual features or making the software easier to modify? The key is the adjective, presumptive. YAGNI is about features that aren't needed now and it's uncertain whether they ever will be.

Silhouette 8y ago
This seems awfully close to a No True Scotsman argument. The Fowler quote was, "Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify." If we exclude features we definitely do want from consideration, so we're only talking about presumptive features, and if we exclude actually implementing those presumptive features, so we're only talking about "capabilities built into the software to support a presumptive feature", and if we then further exclude things that "make the software easier to modify", then how much development is really left for YAGNI to affect? I can't speak for anyone else, but when I write new code, it is generally either implementing some specific functionality that we want right now or improving the common foundations of the system in some way. The usual reasons for the latter would be either gaining some immediate benefit, such as improved performance or robustness, or making the code easier to modify so we can then gain some benefit. By Fowler's argument, I don't see much of a middle ground where YAGNI would mean anything, unless maybe a developer is in the habit of starting to develop code for some specific feature when there isn't actually any requirement for it yet, but why would anyone do that anyway?
- combatentropy 8y ago
  Fear. I worked with a programmer that did it a lot. What if the customer wants this, or what if the customer wants that? And his reason was just what the article highlights: "I programmed it now so I won't have to program it later." It doesn't make sense unless you are trying to get a program done for good and hope never to have to work on it again afterward.
  - Silhouette 8y ago
    I'm still struggling to understand how that happens. You've got a professional programmer who's just randomly writing code for imaginary requirements they made up? I mean sure, obviously that's bad practice and unnecessary, but who does that, and why do their managers and technical leaders allow it? I've always taken YAGNI to be a cautionary principle about over-engineering and over-generalising software designs before there's sufficient expectation that the extra flexibility will justify the implementation cost. I'm not sure I've ever seen it used (or needed) in the context of someone just randomly adding arbitrary functionality because they felt like it, and it had never previously occurred to me that someone might restrict the term to only that scenario as Fowler seems to be doing in the quoted comment.
    - combatentropy 8y ago
      The features aren't random. They're usually related to other features. They might be variations on a feature. For example, what if the user doesn't like the apps fonts and colors? Let's let them customize the look and feel to whatever they want. Or we've made this app that let's you send text messages to people, but what if it needs to be sent to an international number? Suppose this feature is right now unnecessary because the app is just for sending text messages among employees at a company that is situated in Wichita. These aren't crazy features, but they're unnecessary and may never be necessary. As to "why do their managers and technical leaders allow it," often they are the very people who spearhead it. Or in my case, our team was embedded in a non-software company, and our leaders didn't understand exactly what we did, so they were hands-off.
      - lfowles 8y ago
        As a resident, Wichita* :)
      - Silhouette 8y ago
        Fair enough. If you've seen examples of that sort of thing actually happening in practice, I defer to your experience, and we can certainly agree that they are unnecessary and effort shouldn't be spent on them!
- hinkley 8y ago
  I'm not satisfied by his criteria. There's a particular design failure mode where an emphasis on 'easier to modify' results in a codebase that's difficult to follow. You're making some future code change easier at the cost of all current code changes. You can infer a concern about overall cost of modification into his statement, and claim that such a person is increasing the cost of code modification, but it's dangerous to leave it unsaid.

Silhouette 8y ago

This seems awfully close to a No True Scotsman argument. The Fowler quote was, "Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify." If we exclude features we definitely do want from consideration, so we're only talking about presumptive features, and if we exclude actually implementing those presumptive features, so we're only talking about "capabilities built into the software to support a presumptive feature", and if we then further exclude things that "make the software easier to modify", then how much development is really left for YAGNI to affect? I can't speak for anyone else, but when I write new code, it is generally either implementing some specific functionality that we want right now or improving the common foundations of the system in some way. The usual reasons for the latter would be either gaining some immediate benefit, such as improved performance or robustness, or making the code easier to modify so we can then gain some benefit. By Fowler's argument, I don't see much of a middle ground where YAGNI would mean anything, unless maybe a developer is in the habit of starting to develop code for some specific feature when there isn't actually any requirement for it yet, but why would anyone do that anyway?

combatentropy 8y ago
Fear. I worked with a programmer that did it a lot. What if the customer wants this, or what if the customer wants that? And his reason was just what the article highlights: "I programmed it now so I won't have to program it later." It doesn't make sense unless you are trying to get a program done for good and hope never to have to work on it again afterward.
- Silhouette 8y ago
  I'm still struggling to understand how that happens. You've got a professional programmer who's just randomly writing code for imaginary requirements they made up? I mean sure, obviously that's bad practice and unnecessary, but who does that, and why do their managers and technical leaders allow it? I've always taken YAGNI to be a cautionary principle about over-engineering and over-generalising software designs before there's sufficient expectation that the extra flexibility will justify the implementation cost. I'm not sure I've ever seen it used (or needed) in the context of someone just randomly adding arbitrary functionality because they felt like it, and it had never previously occurred to me that someone might restrict the term to only that scenario as Fowler seems to be doing in the quoted comment.
  - combatentropy 8y ago
    The features aren't random. They're usually related to other features. They might be variations on a feature. For example, what if the user doesn't like the apps fonts and colors? Let's let them customize the look and feel to whatever they want. Or we've made this app that let's you send text messages to people, but what if it needs to be sent to an international number? Suppose this feature is right now unnecessary because the app is just for sending text messages among employees at a company that is situated in Wichita. These aren't crazy features, but they're unnecessary and may never be necessary. As to "why do their managers and technical leaders allow it," often they are the very people who spearhead it. Or in my case, our team was embedded in a non-software company, and our leaders didn't understand exactly what we did, so they were hands-off.
    - lfowles 8y ago
      As a resident, Wichita* :)
    - Silhouette 8y ago
      Fair enough. If you've seen examples of that sort of thing actually happening in practice, I defer to your experience, and we can certainly agree that they are unnecessary and effort shouldn't be spent on them!
hinkley 8y ago
I'm not satisfied by his criteria. There's a particular design failure mode where an emphasis on 'easier to modify' results in a codebase that's difficult to follow. You're making some future code change easier at the cost of all current code changes. You can infer a concern about overall cost of modification into his statement, and claim that such a person is increasing the cost of code modification, but it's dangerous to leave it unsaid.