[AlotOfReading]

It's extreme to demonstrate the point, but it's not contrived. Realtime deadlines are a completely normal requirement for the systems I work on. I have change reqs on my desk right now that specify a full reboot back to network responsiveness in <=300ms. That definitely changes how the system is designed.

[pydry]

It being extreme is what makes it contrived.

It's also a requirement programmers often overemphasise due to the McNamara fallacy.

[Supermancho]

Contrived does not mean unrealistic. I have seen many extreme requirements come down on short notice. Over time, the peter priciple guarantees that there will be a middle manager that miscommunicates an agenda they dont fully understand, then push an emergency change down the hierarchy.

[pydry]

No, but programmers fetishize speed. Customers usually value it far, far less than many programmers think.

Ive seen many a programmer gagging to rearchitect to speed up an app 2x or 3x when there are 9 other things a customer genuinely wants first and the programmer refuses to believe it.

Most recently it was on a RAG system where an extra 500ms would surely have been appreciated but the right answer mattered 100x more.

[AlotOfReading]

You missed the point of the example. The parent said any design that has to change with a single requirement shift is a bad design. So I gave a requirement that virtually any design would have to change to accommodate. It doesn't preclude the existence of other, more plausible requirements that shift designs. I even provided a real example of one, which you've ignored.