Completely untrue. Every design can be destroyed by a single poorly-thought out requirement. I can take down Facebook's design just by saying "any edit must immediately be visible to all users".
That's a straw man argument. Your new requirement is physically impossible. No software team can break the laws of physics.
So the real question is what exactly do you mean by "immediately"? There are many answers with different pros/cons and cost. And I bet the solution won't impact 99% of the software Facebook has already written.
My new requirement is NOT physically impossible. I did not mean "immediately" as in "zero milliseconds", it meant strong read-after-write consistency. It makes facebook so slow and unscalable as to be unusable. Facebook deliberately decided that stale reads are worth it for responsiveness and scale.
So your argument is that no solution could satisfy your new requirement, not even if Facebook rewrote the entire system from scratch.
If that's the case, then your example doesn't really address what we're discussing: whether software can be designed to remain flexible under realistic requirement changes.
A stronger argument would be to give an example of a realistic requirement change that would force all possible software architecture to be rewritten from scratch. Do you have an example like that?
Comments
Completely untrue. Every design can be destroyed by a single poorly-thought out requirement. I can take down Facebook's design just by saying "any edit must immediately be visible to all users".
That's a straw man argument. Your new requirement is physically impossible. No software team can break the laws of physics.
So the real question is what exactly do you mean by "immediately"? There are many answers with different pros/cons and cost. And I bet the solution won't impact 99% of the software Facebook has already written.
My new requirement is NOT physically impossible. I did not mean "immediately" as in "zero milliseconds", it meant strong read-after-write consistency. It makes facebook so slow and unscalable as to be unusable. Facebook deliberately decided that stale reads are worth it for responsiveness and scale.
So your argument is that no solution could satisfy your new requirement, not even if Facebook rewrote the entire system from scratch.
If that's the case, then your example doesn't really address what we're discussing: whether software can be designed to remain flexible under realistic requirement changes.
A stronger argument would be to give an example of a realistic requirement change that would force all possible software architecture to be rewritten from scratch. Do you have an example like that?
No, read my comment again. They could do it but it would absolutely destroy the responsiveness of the app.