Code Leader: Using People, Tools, and Processes to Build Successful Software

9.1. Limiting Surface Area

Remember the "if you build it, they will come" baseball-field theory? The corollary in software development should be "if you make it public, they will take a dependency on it." A common problem associated with supporting software libraries has to do with customers using more of your code than you had intended. It is not unusual at all to look back on support problems with statements such as "I never thought anyone would do that."

The reality is that anything in your software libraries that you make public (in the programming language sense, that is, creatable by anyone) you will have to support forever. Even if you thought nobody would use a particular class, or if it were undocumented and you hoped nobody would notice it, you still have to support it indefinitely. Once a public interface is out in the wild, it becomes very difficult to change. This can be particularly troubling when it involves undocumented classes that you considered "internal." Most of the programming languages that are popular today involve bytecode of some kind, or interpreted script. Either way, anyone consuming your code basically has access to — or at least visibility into — your entire implementation. Those undocumented classes are still discoverable, and they may well end up getting used by customers.

Once those undocumented classes start being used by your customers, they become a full-fledged part of your public interface and have to be supported as such. It is very difficult ...