5 ms·

"May very well speed up the rest of the implementation". Experience tells us that the rare cases where it does are vastly outweighed by the cases where they do

"May very well speed up the rest of the implementation". Experience tells us that the rare cases where it does are vastly outweighed by the cases where they do not. "But again, there is a large continuum of possible approaches here, and insisting on reducing it all down to either "do everything" or "YAGNI" is really kind of bewildering." This is the "I'm being more reasonable" logical fallacy. There is a large continuum of possible approaches to the standard prisoners dilemma, but it turns out that there is an optimal solution. In my experience, YAGNI is an optimal solution to software engineering. Sure, there are plenty of times where it doesn't work out. But in any given solution, without a time machine, YAGNI is the sanest strategy. If this is bewildering to you then you don't have enough data.

eridius 11y ago
> This is the "I'm being more reasonable" logical fallacy. No it's not. It's me outright rejecting the claim that "YAGNI is an optimal solution to software engineering". You can certainly say YAGNI in specific situations, but as a general approach of never building anything that's not immediately needed this very moment, I strongly disagree. At this point, I'm starting to suspect this comes down to the difference between "programming" and "software engineering" (which is to say, the difference between solving specific problems vs making core architectural decisions).
- lowbloodsugar 11y ago
  I agree, it is "programming" vs "software engineering". You are looking at the problem as a programmer, and making reasonable assumptions about how to solve the problem using objects and graphs and interfaces and models. If we had a better model, our project will go faster and be better. I am looking at it as an engineer, and seeing what actually happens in real life when real humans build real code. If we had working code for simple problem A, then when we get to more complex problem B, our developers will have more experience, better morale, and better support from management who have happy customers.
  - eridius 11y ago
    Your response is actually very surprising. I'm looking at the problem as a software engineer, who has to make architectural decisions about the applications I'm building. You're looking at it like a programmer. YAGNI is very much not an "engineering" response, it's a "programming" response. Engineering is all about careful, methodical design and architecture and planning for the future maintenance of the product. YAGNI is pretty much the antithesis of this. I'm curious what kind of software you work on. Most of the software I do is applications / frameworks development. Planning ahead is very important when developing the architecture of an application, and is doubly-so when doing any kind of API design (both when developing frameworks and when developing reusable components inside of applications). You certainly don't need to implement everything up-front, but you do have to understand the future requirements and design appropriately. Failure to do so leads to blowing out time / budget estimates later when you realize your code isn't maintainable anymore and all the "quick" implementations people did to avoid having to make architectural decisions are now so fragile and dependent upon assumptions the implementor probably didn't even realize they were making that you can't change anything without having large ripple effects.
    - lowbloodsugar 11y ago
      I am the lead architect of a public facing data platform for a fortune 500 company. I influence over 60 engineers through my team of architects, and indirectly influence countless other teams deploying to our platform. My background is start-ups. We do not suffer the failure modes you describe in your second paragraph. I love my job.
      - eridius 11y ago
        I take it "data platform" means server-side work? I was guessing that was your line of work. In my experience, server-side programming and native client software (applications, frameworks, or systems) are pretty radically different in a lot of non-obvious ways. I think this might be one of them.
        11y ago
Silhouette 11y ago
In my experience, YAGNI is an optimal solution to software engineering. Of course it isn't. For example, it is suboptimal any time you have two features, the total cost of implementing both together is less than the total cost of implementing one then the other separately, and it turns out that you do need both in the end. You might not have known it up-front, but your outcome was still worse in the end. Moreover, the greater the overhead of implementing the two features separately, the lower the probability of eventually needing both required for doing both together to be the strategy with the better expected return. If this is bewildering to you then you don't have enough data. Or just different data that leads to a different conclusion. Some of the YAGNI sceptics here have also been doing this stuff a long time, but apparently with quite different experiences to you.
- lowbloodsugar 11y ago
  But you haven't factored in the cost of the time machine. How much did that cost you?
  - Silhouette 11y ago
    My argument is pure logic, based on a direct comparison of the total cost of doing it both ways. No fudge factors are required. The conclusion fails and so YAGNI always gives the best possible result only if there is no real world situation where the initial assumptions in my argument hold. Clearly there are actually numerous situations where those assumptions do hold, so YAGNI cannot be trusted to give the best final outcome in all cases.
    - lowbloodsugar 11y ago
      There are no real world situations where the initial assumptions in your argument hold because you do not own a time machine. A time machine is necessary for you to distinguish between the situation you describe vs. any one of the countless ways that your situation could differ from your expectation as time unfolds. Such as the pirates getting wiped out by the Navy. Suppose instead of a pair of features, you have twenty pairs of features. For most of those pairs: a) The second item isn't really needed. b) The second item is vastly more complicated than the first, and delays revenue c) The se Wait, here's an article that describes nicely the other possible outcomes and their costs: http://martinfowler.com/bliki/Yagni.html http://martinfowler.com/bliki/Yagni.html
bsder 11y ago
> Experience tells us that the rare cases where it does are vastly outweighed by the cases where they do not. I do not agree with this. My experience does not match this. As I tell my clients regularly, "Yes, I spent one day implementing that feature. But I spent 4 days talking to your folks trying to figure out what you actually needed, and 3 more days getting ready for what they are about to ask for." Startup folks are fond of thinking that they have to move too fast for thinking or they are going bankrupt. That's rarely true. And, if it is, you're probably hosed anyway.

eridius 11y ago

> This is the "I'm being more reasonable" logical fallacy. No it's not. It's me outright rejecting the claim that "YAGNI is an optimal solution to software engineering". You can certainly say YAGNI in specific situations, but as a general approach of never building anything that's not immediately needed this very moment, I strongly disagree. At this point, I'm starting to suspect this comes down to the difference between "programming" and "software engineering" (which is to say, the difference between solving specific problems vs making core architectural decisions).

lowbloodsugar 11y ago
I agree, it is "programming" vs "software engineering". You are looking at the problem as a programmer, and making reasonable assumptions about how to solve the problem using objects and graphs and interfaces and models. If we had a better model, our project will go faster and be better. I am looking at it as an engineer, and seeing what actually happens in real life when real humans build real code. If we had working code for simple problem A, then when we get to more complex problem B, our developers will have more experience, better morale, and better support from management who have happy customers.
- eridius 11y ago
  Your response is actually very surprising. I'm looking at the problem as a software engineer, who has to make architectural decisions about the applications I'm building. You're looking at it like a programmer. YAGNI is very much not an "engineering" response, it's a "programming" response. Engineering is all about careful, methodical design and architecture and planning for the future maintenance of the product. YAGNI is pretty much the antithesis of this. I'm curious what kind of software you work on. Most of the software I do is applications / frameworks development. Planning ahead is very important when developing the architecture of an application, and is doubly-so when doing any kind of API design (both when developing frameworks and when developing reusable components inside of applications). You certainly don't need to implement everything up-front, but you do have to understand the future requirements and design appropriately. Failure to do so leads to blowing out time / budget estimates later when you realize your code isn't maintainable anymore and all the "quick" implementations people did to avoid having to make architectural decisions are now so fragile and dependent upon assumptions the implementor probably didn't even realize they were making that you can't change anything without having large ripple effects.
  - lowbloodsugar 11y ago
    I am the lead architect of a public facing data platform for a fortune 500 company. I influence over 60 engineers through my team of architects, and indirectly influence countless other teams deploying to our platform. My background is start-ups. We do not suffer the failure modes you describe in your second paragraph. I love my job.
    - eridius 11y ago
      I take it "data platform" means server-side work? I was guessing that was your line of work. In my experience, server-side programming and native client software (applications, frameworks, or systems) are pretty radically different in a lot of non-obvious ways. I think this might be one of them.
      - 11y ago

Silhouette 11y ago

In my experience, YAGNI is an optimal solution to software engineering. Of course it isn't. For example, it is suboptimal any time you have two features, the total cost of implementing both together is less than the total cost of implementing one then the other separately, and it turns out that you do need both in the end. You might not have known it up-front, but your outcome was still worse in the end. Moreover, the greater the overhead of implementing the two features separately, the lower the probability of eventually needing both required for doing both together to be the strategy with the better expected return. If this is bewildering to you then you don't have enough data. Or just different data that leads to a different conclusion. Some of the YAGNI sceptics here have also been doing this stuff a long time, but apparently with quite different experiences to you.

lowbloodsugar 11y ago
But you haven't factored in the cost of the time machine. How much did that cost you?
- Silhouette 11y ago
  My argument is pure logic, based on a direct comparison of the total cost of doing it both ways. No fudge factors are required. The conclusion fails and so YAGNI always gives the best possible result only if there is no real world situation where the initial assumptions in my argument hold. Clearly there are actually numerous situations where those assumptions do hold, so YAGNI cannot be trusted to give the best final outcome in all cases.
  - lowbloodsugar 11y ago
    There are no real world situations where the initial assumptions in your argument hold because you do not own a time machine. A time machine is necessary for you to distinguish between the situation you describe vs. any one of the countless ways that your situation could differ from your expectation as time unfolds. Such as the pirates getting wiped out by the Navy. Suppose instead of a pair of features, you have twenty pairs of features. For most of those pairs: a) The second item isn't really needed. b) The second item is vastly more complicated than the first, and delays revenue c) The se Wait, here's an article that describes nicely the other possible outcomes and their costs: http://martinfowler.com/bliki/Yagni.html http://martinfowler.com/bliki/Yagni.html

bsder 11y ago

> Experience tells us that the rare cases where it does are vastly outweighed by the cases where they do not. I do not agree with this. My experience does not match this. As I tell my clients regularly, "Yes, I spent one day implementing that feature. But I spent 4 days talking to your folks trying to figure out what you actually needed, and 3 more days getting ready for what they are about to ask for." Startup folks are fond of thinking that they have to move too fast for thinking or they are going bankrupt. That's rarely true. And, if it is, you're probably hosed anyway.