Today a was listening to the great Q&A session with Anders Hejlsberg. But the post is not about the session itself, the thing that touched my ‘heart' is that he mentioned a great point about the language design. There was a question to him about a missing feature in C#, and his answer was that a language is not (only) about features but it is more about "how all the features do they play together".
I think it is very important point, and it applies not only language design but to design and architecture in general. While designing or architecting a project trying to add more ‘features' to the design (or architecture) we often forget to think how do they play together. And is very hard to analyze their impact from "play together" perspective.
I think there someone will say that design (or architecture) is better when we can add features independently without affecting other packages, components, etc.. and I agree with that, but finally the software is about interaction on different levels (classes, packages, components,...) and the meaning is how these interaction play together when is added a new "feature" and doesn't matter at which level of abstraction it is introduced.
Yes, we can unit testing for introducing a new feature, but it will solve the problem only partially answering the compile and covered business cases if they are broken or not, but it will not say anything about how ‘nicely do they play together ' all the features.
Another technique is evaluative design (or architecture) where we can add small features and constantly refactoring to a better design every time we see a better way of doing. Last but not least technique that comes to mind is DDD techniques that make more transparent the entire design process in case of complex business solutions.
I think you will be agree with me that there is not general technique that can say to you about your design "features play ability" but there are techniques that can make it better (doesn't matter these features are functional or non-factional). But it is important to take in consideration when we introduce a new feature how it will fit together with other existing features.
(PS: Just thoughts, maybe Interface Segregation Principle applied ad various levels of abstraction can be used as a techniques in order to design a better "features play ability" ? )