To me, one of the central ideas in programming, and engineering in general, has been how you connect smaller components to build bigger ones. Whether the structures arising from these connections are thought of as layering of components on top of each other (hierarchical/vertical) or are thought of as components living at the same level (horizontal), the interfaces that enable connections are the key to how well the sum total of these parts work. Interfaces are also the key to how easily some of these connections can be broken and re-connected. Description of an interface that I have liked best (by which all I mean is that it was closest to how I myself looked at interfaces) is the one provided by Parnas – “interfaces are assumptions that components make about each other”. As designers, our central goal should be to make these assumptions as explicit and self enforcing as possible. Implicit assumptions are, indeed, the root cause of much evil in the software world.
Since a programming language is just a tool for instructing a general purpose machine to perform certain activities (i.e. program the machine), the complexity rarely lies in the programming language. The complexity lies in the world and the abstractions that we agree upon for simulating certain aspects of the real world in our systems. We often try to bridge gaps in our understanding of the world by making assumptions. In an ideal (simpler, non-real) world, we wouldn’t have to make any assumptions. In the real world, the best we can do is to make every assumption as explicit as possible and get all stakeholders to buy into those assumptions.
An assumption can be made explicit through documentation but its better if the assumption can be formally described and automatically enforced. Good programs force developers to think through and be conscious of the assumptions even in absence of any documentation.
The idea of making assumptions explicit is not restricted to software interfaces alone. It is just as important to keep this in mind when you gather requirements, write specifications, create design documents, and design and document your processes. It is so important that I, at times, feel that programmers should have lawyers working with them. Which (sort of) leads me to my other complaint: configuration heavy frameworks. We have spent a lot of time and effort making our programming languages (and APIs to certain extent) explicit and self enforcing, but with every file based configuration (it’s actually not just file based but files will suffice for the time), we tend to hide some of the assumptions in an isolated, implicit and non-enforceable piece. Google’s Guice tries to avoid configuration files and Spring has been supporting annotation based dependency injection for a while now but the overwhelming trend even today seems to be: when in doubt, control by configuration. The specification designers of the Java Enterprise Editions realized this several years ago but there still are configuration heavy frameworks out there. As a programmer, when I start looking into a new framework or a development environment, it’s not the core technology or a new programming language that takes time to learn. It’s always the configuration that takes the longest to figure out.
