> It's hard to anticipate future requirements. It's not about that, it's about keeping what you do nimble enough to always be ready for change when it comes.

> It's hard to anticipate future requirements. It's not about that, it's about keeping what you do nimble enough to always be ready for change when it comes. That means not having duplication in the system, having things well factored and encapsulated so there's a distinction between the abstract and the implementation so at any time any component can be made a change point and become pluggable. What makes a good architecture good is that it can be changed without scrapping the whole thing or breaking the whole thing. > Where good people win is that they adapt quickly when there are signs that the design doesn't work. It's not that they do adapt quickly, it's that they "can". > A lot of people just "stick to the plan" although everybody knows that it won't work. Because they're stuck with a bad design that can't be changed due to issues like bad factoring, lots of code duplication and copy pasting, etc.