15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up. So true. Parnas' pap

15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up. So true. Parnas' paper on information hiding and decomposing into modules is of course also about choosing the interfaces https://docs.google.com/viewer?url=http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf https://docs.google.com/viewer?url=http://www.cs.umd.edu/cla... (bonus: he describes the genesis of the paper, see the "quick view" of the top of this google search https://www.google.com/search?q=filetype%3Apdf+parna+on+the+criterion+for+decomposing+into+modules https://www.google.com/search?q=filetype%3Apdf+parna+on+the+...) Unfortunately, once you've chosen interfaces that hide the details and things likely to change, it becomes harder to change the interfaces, in case you were wrong in your predictions of what will change in the future... Or, if you just didn't understand the best way to approach the system... (how could that happen?) It's hard to change because other modules depend on this interface. Unit tests operate on the interfaces between modules, so they need to change too... and you won't have the safety net they provide. Documentation must change. etc. Therefore, in practice, interfaces are not changed.