As highlighted by Bill Higgins in his post, both transparency and abstraction have their own merits and compete with each other. Thoughts on balancing between these two in most cases lead us back to the basic principles of software engineering. Some aspects that come to my mind are:
Separation of Concerns
As written by Bill himself, this has a direct impact on making the lives of people easier when they try to digest a system apart from other benefits. At higher levels of system decomposition, a high degree of transparency is observed in terms of functionality and fades away when lower levels are reached. And hence separation of concerns at higher levels is well understood even by the non technical which is not the case when lower levels are reached where technical abstractions start to dominate. You need a technical mind to understand what happens here, but still the separation of concerns ease your life. A sub tactic, abstracting common services is also a proven technique.
Levels of Abstraction
The “sea level of abstractions” is the level at which a common pool of developers work. Abstractions above and beyond this level are new to them and have to be learnt if they have to harness the new knowledge. Take for example the Eclipse framework. If a typical Java developer is to develop a modeling tool based on latest Eclipse technologies, he/she has to learn many things (say SWT, JFace, UML2, EMF, GMF,…). All these are pretty handy abstractions once you know how to use them, but are bitter at the start. Though there’s nothing much a new person can do, transparency can effectively be improved if the “sea level of abstractions” of a given group is uplifted phase by phase. This naturally happened to the Eclipse folks where they had time to build abstractions one on top of another and test each abstraction before another technology is developed. New to Eclipse, SWT is your starting point. Start reading now! Alternatively, you can start with OSGi. Hey, there’s more. Why not you start reading the UML infrastructure, then superstructure, and then UML2,…?
Good Documentation
If transparency is the ability to see through, you need something to look at. Let there be short and concise documentation about the abstractions found in the system! BTW, the recent 6000 page OOXML specification from Microsoft is an example where transparency melts down merely due to the 6000 pages irrespective of whether it will be accepted by the ISO/IEC committee or not.
Fault Masking
At least a good exception handling mechanism which throws predictable exceptions would be of tremendous help. I am in view with Booch’s point of view: Good abstractions fail in predictable ways. Make them fail like that even at the code level! Even with many other leaks. Careful mapping of predictable failures of an abstraction into well thought exceptions easily highlights the problems when they occur and allows quick identification of the problem origin.
Consistency
Accomplishing the same task in many places in the same way will again improve the transparency. You have to learn only once. But one has to spend some time to figure out a common pattern of abstraction that can be injected into many places (where diverse abstractions take place) of the system. So there will be one abstraction abstraction process. Hmmm… This reminds me the distinctions between modeling and meta modeling (say UML/MOF). In the same way, I am suggesting a meta abstraction process which will have some similarities to Structural Modeling as described in A Case Study in Structural Modeling and Structural Modeling: An Application Framework and Development Process for Flight Simulators.