2 ms·

Well, when you start bringing the timeline in as close the following week, then you're talking about something very different (or at least vs. what I've been co

Well, when you start bringing the timeline in as close the following week, then you're talking about something very different (or at least vs. what I've been considering). Because, even with iterative/agile development, a week out can likely be considered in-scope (or close enough). So, narrowing the timeline so dramatically fundamentally changes this entire discussion. YAGNI's statement implies that there's a reasonable degree of uncertainty with regard to the features you're considering. However, there is generally much less uncertainty about what you'll be building in the following week. The requirements are essentially known for all intents and purposes. So, at that point, it's more like, "I Know We Need This", because you're essentially driving it from the current requirements. So, I think the real determinant is whether you're looking at current requirements, vs. trying to anticipate future requirements. If you're doing the latter then, I think we just disagree. And, if your experience is that extrapolating requirements far off into the future has been helpful on average, then we have definitely worked on different kinds of projects.

Silhouette 11y ago
Well, when you start bringing the timeline in as close the following week, then you're talking about something very different (or at least vs. what I've been considering). Perhaps this is where the crossed wires happened, then. To me, this is all a matter of degrees. I know exactly what I need to build immediately -- what code I'm writing this morning, what tests I'm currently trying to make pass, or however you want to look at it. I also have a very clear idea of what I need to build later this week. I have some idea of what I need to build by the end of the month. I have a tentative idea of what I'll need to build in three months. On most projects, I probably have very little confidence in what I'll be building a year from now. When I'm designing and coding, the amount of weight I give to potential future needs is based on that sliding scale of confidence. If I'm writing two cases for something right now and expect to need the third and final possibility next week, I'll probably just write them all immediately, so that whole area is wrapped up and I don't have to shift back to look at this part of the code again in the immediate future. For something that I will probably need in a few weeks, it's less likely that I'll implement it fully right now, but I might well leave myself a convenient place to put it if and when the time comes if that doesn't require much work. For me, the latter is sometimes a bit like deliberately leaving the final step of a routine task unfinished at the end of a working day so I can get going the next morning with a quick and easy win -- it's as much about the positive mindset as any expectation that doing something immediately vs. very soon will make any practical difference to how well it gets done. Obviously as I look further ahead, confidence in specific needs tends to drop quite sharply on most projects. For something tentative that is being discussed as a possible future requirement for later this year but with no clear spec yet, it's unlikely that I would write any specific code for it at all at this stage. However, I might still take into account likely future access patterns for data in my system if I'm choosing between data structures that are equally suitable for the immediate requirements. I might take into account the all-but-certainty that we will need many variations of some new feature when planning the architecture for that part of the system and design in a degree of extra flexibility, even though we have no clear idea of exactly which variations they will be yet and I'm not actually writing any concrete implementations beyond the first one at this stage. And, if your experience is that extrapolating requirements far off into the future has been helpful on average, then we have definitely worked on different kinds of projects. That's not really how I look at it. I'm not so much extrapolating (a.k.a. guessing) specific requirements far ahead. I'm just allowing for the possibility that I may have some useful knowledge about future needs without necessarily having all the details yet. If I do, I will take advantage of that to guide my decisions today to the extent that confidence justifies doing so. The amount of actual change in designs or code that results will vary with both the level of confidence I currently have in whatever potential requirements we are talking about and in the assessment of how much effort is required to allow for them now vs. how much effort will potentially be saved later if the expectation is accurate.

Silhouette 11y ago

Well, when you start bringing the timeline in as close the following week, then you're talking about something very different (or at least vs. what I've been considering). Perhaps this is where the crossed wires happened, then. To me, this is all a matter of degrees. I know exactly what I need to build immediately -- what code I'm writing this morning, what tests I'm currently trying to make pass, or however you want to look at it. I also have a very clear idea of what I need to build later this week. I have some idea of what I need to build by the end of the month. I have a tentative idea of what I'll need to build in three months. On most projects, I probably have very little confidence in what I'll be building a year from now. When I'm designing and coding, the amount of weight I give to potential future needs is based on that sliding scale of confidence. If I'm writing two cases for something right now and expect to need the third and final possibility next week, I'll probably just write them all immediately, so that whole area is wrapped up and I don't have to shift back to look at this part of the code again in the immediate future. For something that I will probably need in a few weeks, it's less likely that I'll implement it fully right now, but I might well leave myself a convenient place to put it if and when the time comes if that doesn't require much work. For me, the latter is sometimes a bit like deliberately leaving the final step of a routine task unfinished at the end of a working day so I can get going the next morning with a quick and easy win -- it's as much about the positive mindset as any expectation that doing something immediately vs. very soon will make any practical difference to how well it gets done. Obviously as I look further ahead, confidence in specific needs tends to drop quite sharply on most projects. For something tentative that is being discussed as a possible future requirement for later this year but with no clear spec yet, it's unlikely that I would write any specific code for it at all at this stage. However, I might still take into account likely future access patterns for data in my system if I'm choosing between data structures that are equally suitable for the immediate requirements. I might take into account the all-but-certainty that we will need many variations of some new feature when planning the architecture for that part of the system and design in a degree of extra flexibility, even though we have no clear idea of exactly which variations they will be yet and I'm not actually writing any concrete implementations beyond the first one at this stage. And, if your experience is that extrapolating requirements far off into the future has been helpful on average, then we have definitely worked on different kinds of projects. That's not really how I look at it. I'm not so much extrapolating (a.k.a. guessing) specific requirements far ahead. I'm just allowing for the possibility that I may have some useful knowledge about future needs without necessarily having all the details yet. If I do, I will take advantage of that to guide my decisions today to the extent that confidence justifies doing so. The amount of actual change in designs or code that results will vary with both the level of confidence I currently have in whatever potential requirements we are talking about and in the assessment of how much effort is required to allow for them now vs. how much effort will potentially be saved later if the expectation is accurate.