Deferring choices also means that more alternatives can be considered since it gives them time to mature, catch up or even be created.
I was once asked why i previous project I worked on used RabbitMQ and not Kafka for the messaging system. The answer was pretty simple: Kafka wasn't really a thing at the time.
How have developers changed over time as they gain more experience? Does anyone ever move from design later to earlier? I doubt it.
Also, how much time has been wasted designing for requirements that haven’t been flushed out yet. It’s not just devs who don’t know what to build, users are also often just starting to reason about many parts of the system. Something in their hands helps them to think clearly.
The first challenge is that timing is a tradeoff & folks don’t recognize the tradeoff. The second is that people don’t know how to respond to the tradeoff or change the curves.
Every BDUF proponent I've ever read or conversed with overlooks the huge assumption they are making, which is what you're saying here (I think). Put another way: Would a design you produce on Day N of a project be of the same "quality"/maturity/effectiveness as the design you produce on Day N+1? Very (very, very, very) few developers or architects I've worked with in my 25+ years can honestly answer "yes" to that question. And if the answer is "Maybe," "Usually", or some other hedging form of "No," then the calculus that purports to prove early design is a benefit, is utterly flawed.
Is it possible to describe this timing more precisely, so that we can describe timing approaches more specifically? In practice I find myself thinking in terms of “I’ll design the next features which could be implemented immediately, but not features which depend on those features”. Here, depth of unimplemented dependencies defines early-to-late.
I'm not really looking for too much precision. We're in a tradeoff space, so there's an area of okay answers in the middle & dramatically worse answers on either end. As long as I am 1) somewhere in the middle & 2) looking to bend the shape of the curves so I can eventually end up in a better place, then I'm okay.
That's for most projects. Some projects have 2 very steep curves so the area of "acceptable" in the middle is narrow compared to the areas of "horrible" on the edges. Then yes, I'd like more precise analysis.
A heuristic like you suggest makes sense to me. At one point I deliberately stopped designing for anything more than 6 months out. Development went better, so I went to 1 month out. Even better. 1 week. Even better. Test case by test case, even better. That's how I got to Empirical Design.
I'm thinking a lot trying to understand the fans of upfront design (not sure from which size it could be called big, but even a week of writing the design doc before writing a line of code is too big for me nowadays). So, usually the discussions with upfront design lovers are getting to the dead end. I feel it is because they are not honest enough with their arguments.
One though came to my mind, is that perhaps there are personal incentives involved. Usually those are architects, teamleads, techleads or younger wannabes of above, those are doing only the "cool" stuff (design/architecture), there the process of designing is separated from the actual implementation. So, by admitting incremental/evolutionary evolving/emprical design they will loose their title and/or prestige.
Deferring choices also means that more alternatives can be considered since it gives them time to mature, catch up or even be created.
I was once asked why i previous project I worked on used RabbitMQ and not Kafka for the messaging system. The answer was pretty simple: Kafka wasn't really a thing at the time.
How have developers changed over time as they gain more experience? Does anyone ever move from design later to earlier? I doubt it.
Also, how much time has been wasted designing for requirements that haven’t been flushed out yet. It’s not just devs who don’t know what to build, users are also often just starting to reason about many parts of the system. Something in their hands helps them to think clearly.
The first challenge is that timing is a tradeoff & folks don’t recognize the tradeoff. The second is that people don’t know how to respond to the tradeoff or change the curves.
Every BDUF proponent I've ever read or conversed with overlooks the huge assumption they are making, which is what you're saying here (I think). Put another way: Would a design you produce on Day N of a project be of the same "quality"/maturity/effectiveness as the design you produce on Day N+1? Very (very, very, very) few developers or architects I've worked with in my 25+ years can honestly answer "yes" to that question. And if the answer is "Maybe," "Usually", or some other hedging form of "No," then the calculus that purports to prove early design is a benefit, is utterly flawed.
Is it possible to describe this timing more precisely, so that we can describe timing approaches more specifically? In practice I find myself thinking in terms of “I’ll design the next features which could be implemented immediately, but not features which depend on those features”. Here, depth of unimplemented dependencies defines early-to-late.
I'm not really looking for too much precision. We're in a tradeoff space, so there's an area of okay answers in the middle & dramatically worse answers on either end. As long as I am 1) somewhere in the middle & 2) looking to bend the shape of the curves so I can eventually end up in a better place, then I'm okay.
That's for most projects. Some projects have 2 very steep curves so the area of "acceptable" in the middle is narrow compared to the areas of "horrible" on the edges. Then yes, I'd like more precise analysis.
A heuristic like you suggest makes sense to me. At one point I deliberately stopped designing for anything more than 6 months out. Development went better, so I went to 1 month out. Even better. 1 week. Even better. Test case by test case, even better. That's how I got to Empirical Design.
I'm thinking a lot trying to understand the fans of upfront design (not sure from which size it could be called big, but even a week of writing the design doc before writing a line of code is too big for me nowadays). So, usually the discussions with upfront design lovers are getting to the dead end. I feel it is because they are not honest enough with their arguments.
One though came to my mind, is that perhaps there are personal incentives involved. Usually those are architects, teamleads, techleads or younger wannabes of above, those are doing only the "cool" stuff (design/architecture), there the process of designing is separated from the actual implementation. So, by admitting incremental/evolutionary evolving/emprical design they will loose their title and/or prestige.