>The point is that it's important to decide these decisions prior to starting the project.
It really isn't. Again, that's when the least is known. I think a much better point to set a particular standard is when there's some sort of team disagreement that would be solved by setting a standard. At which point you'll have more information than you would have had before starting.
> I've seen more than a few engineers throw the term "tech debt" around as a justification for rewriting everything to their preference.
Sure, and that's bad. But it's bad because there's a dispute over the team definition of "good design" that needs to get resolved by the team. One way to avoid that becoming a massive problem is to regularly set/update design decisions as circumstances demand it. Because sticking with bad or out-of-date choices made before the project started is a good way to create the sort of tension and chaos where "rewrite it all in shiny new framework X" can seem like a good idea.
> It really isn't. Again, that's when the least is known. I think a much better point to set a particular standard is when there's some sort of team disagreement that would be solved by setting a standard. At which point you'll have more information than you would have had before starting.
This probably depends on the size of organization, and the likelihood that the product will survive long enough to require such revision. In my line(s) of work, the odds have been high and it's proven critical to make sure these points are clarified early. If the project is likely to be canned in 6 months anyway... then people can do whatever they want :)
While this stance is fundamentally Anti-Agile, I don't see this as a problem. While Agile's emphasis on rapid iteration is correct - my experience has been that folks forget the importance of testing a meaningful hypothesis or achieving a meaningful milestone in these iterations. In a vast number of domains, it's much easier and more effective to do detailed design work then jump straight into coding. The design process should hopefully land the team on the correct thing to build, how they are going to build it, and why they are building it.
It really isn't. Again, that's when the least is known. I think a much better point to set a particular standard is when there's some sort of team disagreement that would be solved by setting a standard. At which point you'll have more information than you would have had before starting.
> I've seen more than a few engineers throw the term "tech debt" around as a justification for rewriting everything to their preference.
Sure, and that's bad. But it's bad because there's a dispute over the team definition of "good design" that needs to get resolved by the team. One way to avoid that becoming a massive problem is to regularly set/update design decisions as circumstances demand it. Because sticking with bad or out-of-date choices made before the project started is a good way to create the sort of tension and chaos where "rewrite it all in shiny new framework X" can seem like a good idea.