Via Tomalak's Realm, a link to the latest Bob Frankston article called "Bad Coupling". This is related to the "leaky abstraction" discussion that took place recently on Joel Spolsky's "Joel on Software" blog.
There seem to be two entirely different ways that abstractions can leak. The first is what I will call original sin:) In this case the development team seeks to make an abstraction that simplifies the development effort, but inadvertantly does not deal with some error or boundary condition well and suddenly, the underlying software reaches out and bites. This kind of leaky abstraction simplifies software development but can lead to nasty failures.
The second way an abstraction can leak is in the ways described in the Frankston article. Well meaning engineers stretch the existing infrastructure abstractions in ways that work, but in a very different dimension than the original abstraction. In these cases, the leaky abstraction complicates software configuration while enabling capabilities that were not envisioned or accepted by the original abstraction's developers.
If you are developing software, the first kind of abstraction will be your biggest concern (unless you are one of those who gets to write the configuration wizards:)). If you are a purchaser or user, the second kind of leaky abstraction will intrude in unpleasant ways. When this second type of leak becomes embedded in the infrastructure, the whole community pays with configuration taxes for a very long time!
10:31:49 AM 
|
