5 ms·

1. My team will not have to throw away our previous work. It works for storm pricing. It is deployed. Customers are using it and we are making money. Your comp

1. My team will not have to throw away our previous work. It works for storm pricing. It is deployed. Customers are using it and we are making money. Your company has yet to deploy a storm pricing model because it got caught in the complexity of the piracy model. 2. When it comes time to write the piracy pricing system, my team has already gained a huge amount of relevant experience from writing the storm pricing system. In my experience a team that already has developed a simpler system will be better able to develop the more complex system. 3. If piracy pricing is a significant risk then it should be prioritized higher. If it is late because you thought it would take two months and it took you four, then you failed to assess risk. A really good way to assess risk is to implement something similar (may I suggest storm pricing). However, in my experience, even if we know we want to ship storm and then piracy immediately after, I will still ask my team to develop storm first to completion. And I will stand any one of my teams up against a team that is going to "do it all in one go", and we'll get them both done before the other team. 4. Basically when you make an argument that is "Suppose you have this situation...", then it is equivalent to saying "This thing happened in the past, and if we had known then what we know now...." They are equivalent because now matter how your frame your "thought experiment", it is guaranteed to never happen in real life. The whole point of YAGNI is that you cannot know the future, and no one ever has. The only way to know for sure that "this is how its going to turn out" is to actually be in the future. So, yes, if you had a time machine, you could argue that big upfront design would work. Of course, if you were to start your argument with "Suppose I had a time machine and I could go back in time and tell my team that the piracy model is a perfect superset of the storm model, but is twice as complex because of x, y and z, but there are no other unknowns, and customers love it, and the Navy doesn't kill the pirates, and so therefore we should do it all in one go" then it would be much more obvious that your argument was flawed.

eridius 11y ago
You're still making some pretty strange assumptions here. An imperfect prediction of the future does not render the prediction meaningless, and making architectural decisions to support expectations of the future does not necessarily mean a significant increase in complexity, it often merely means some upfront "critical thinking" time. In fact, this upfront time may very well speed up the rest of the implementation, even if the predicted future requirements never come to pass, because it produces a more well-thought-out and well-understood architecture, that may be cleaner and more powerful without making the actual implementation any harder. 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.
- lowbloodsugar 11y ago
  "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.
      - 11y ago
fr0styMatt2 11y ago
This still seems to suggest some up-front design though. How do you know that the piracy pricing is going to be a significant risk (as pointed out in 3) unless you think through some of its' design? Why wouldn't the engineers then go into developing the Storm feature with this knowledge, so that they avoid making any decisions that might cause significant rework when it comes time to implement piracy? I can't see how they could assess the risk of the piracy feature without having thought it through and then choose not to take any of that thought into account when implementing the storm pricing feature.
saganus 11y ago
" The only way to know for sure that "this is how its going to turn out" is to actually be in the future." But then what kind of "time resolution" do you use for "in the future"? I mean, of course if you talk about weeks ahead, then yes, why should I plan for something that I may or may not need need in 4 weeks? What is the cutoff then? Next week? Tomorrow? In an hour? 10 minutes? After 34 years of experience, you have fine-tuned this. But there IS a line, right? Maybe not fixed, but there should be one, otherwise you won't do anything unless it's needed like right this nanosecond. Reductio ad absurdum of course, but I'm curious how do you know where to draw the line?.
- lowbloodsugar 11y ago
  We do TDD. The cut-off line is "this test". Anything more than fixing "this test" is waste. We fix "this test" and write another test. Fix it. Maybe refactor. Repeat. So not next month, next week. More like "next 30 seconds". Even if we are scheduled to do the next feature right after this feature, we still wouldn't start writing a unified solution. We'd write a test for A, then fix it, then write another test for A, and then fix that, and keep going until A was done and now we're writing a test for B. That said, if we really don't know what we're doing then we spike. Then we throw it away and rewrite it with TDD. Sounds mental, right?
  - saganus 11y ago
    It might sound mental, but if it works better than the alternatives... then how mental is it actually? Thanks for the explanation. It's actually something I will try. I can't hurt to learn new things, can it?

eridius 11y ago

You're still making some pretty strange assumptions here. An imperfect prediction of the future does not render the prediction meaningless, and making architectural decisions to support expectations of the future does not necessarily mean a significant increase in complexity, it often merely means some upfront "critical thinking" time. In fact, this upfront time may very well speed up the rest of the implementation, even if the predicted future requirements never come to pass, because it produces a more well-thought-out and well-understood architecture, that may be cleaner and more powerful without making the actual implementation any harder. 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.

lowbloodsugar 11y ago
"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.
    - 11y ago

fr0styMatt2 11y ago

This still seems to suggest some up-front design though. How do you know that the piracy pricing is going to be a significant risk (as pointed out in 3) unless you think through some of its' design? Why wouldn't the engineers then go into developing the Storm feature with this knowledge, so that they avoid making any decisions that might cause significant rework when it comes time to implement piracy? I can't see how they could assess the risk of the piracy feature without having thought it through and then choose not to take any of that thought into account when implementing the storm pricing feature.

saganus 11y ago

" The only way to know for sure that "this is how its going to turn out" is to actually be in the future." But then what kind of "time resolution" do you use for "in the future"? I mean, of course if you talk about weeks ahead, then yes, why should I plan for something that I may or may not need need in 4 weeks? What is the cutoff then? Next week? Tomorrow? In an hour? 10 minutes? After 34 years of experience, you have fine-tuned this. But there IS a line, right? Maybe not fixed, but there should be one, otherwise you won't do anything unless it's needed like right this nanosecond. Reductio ad absurdum of course, but I'm curious how do you know where to draw the line?.

lowbloodsugar 11y ago
We do TDD. The cut-off line is "this test". Anything more than fixing "this test" is waste. We fix "this test" and write another test. Fix it. Maybe refactor. Repeat. So not next month, next week. More like "next 30 seconds". Even if we are scheduled to do the next feature right after this feature, we still wouldn't start writing a unified solution. We'd write a test for A, then fix it, then write another test for A, and then fix that, and keep going until A was done and now we're writing a test for B. That said, if we really don't know what we're doing then we spike. Then we throw it away and rewrite it with TDD. Sounds mental, right?
- saganus 11y ago
  It might sound mental, but if it works better than the alternatives... then how mental is it actually? Thanks for the explanation. It's actually something I will try. I can't hurt to learn new things, can it?