Circa 1998 I was a contract programmer for the Queensland government, working alongside other contractors who would often regale me with tales of their experiences developing FRAMEWORKS for other programmers to use. I remember how I would inwardly groan every time I heard about these FRAMEWORKS, but at the time I wrote off my groaning as just simple laziness; reluctance to expend the energy required to understand the subtleties of another's handiwork.

Half a decade later my reflection is that it was indeed laziness of a sort, but more and more I feel that it was justified laziness, the sort of laziness that spurs programmers to make the future easier for themselves and others rather than harder.

I'm not saying frameworks can't make life easier, just that they so often fail in this regard. As Ward says:

Now somebody might say, "Why don't we look forward, look at all the work we have to do? Why don't we design a system that makes all work easy from the beginning?" And if you can pull that off, that's great. It's just that, over and over, people try to design systems that make tomorrow's work easy. But when tomorrow comes it turns out they didn't quite understand tomorrow's work, and they actually made it harder.

In fact, many of my private (almost guilty) ruminations over the last few years been related to this theme. In April 2003 I scribbled a few notes and references on what I perceived to be difficulties with encapsulation:

"Encapsulation is the process of hiding all of the details of an object that do not contribute to its essential characteristics." Booch, 1991. Object-Oriented Design With Applications.

"Encapsulation (Information Hiding). A principle, used when developing an overall program structure, that each component of a program should encapsulate or hide a single design decision... The interface to each module is defined in such a way as to reveal as little as possible about its inner workings." Peter Coad and Edward Yourdon, 1991. Object-Oriented Analysis, 2nd ed.

"At the heart of Object Oriented Programming lies the concept of encrapsulation, whereby the programmer gets to hide all the details, especially the shitty ones."EdwardG, 2004

By encouraging the hiding of complexity, encapsulation does not provide for the inevitable imperfection of code that is produced under pressure. If an encapsulated object proves to be inadequate or defective then the situation is much worse for the maintenance programmer than if they had been exposed to the complexity all along. When this situation arises they must come to terms with unfamiliar code in addition to pinpointing and resolving the defect.

Another problem is that changing any moderately complex object risks inadvertently changing the bahaviour of that object, even if only slightly, and so it is often considered necessary to perform full regression testing.

If the development team has previously had bad experiences with "fixes making things worse" then this otherwise reasonable attitude can tend toward paranoia. And when the object is widely used, the cost of regression testing can outweigh the benefit of the proposed change, especially when a fixed deadline looms.

Some things that don't help:

1. Locally created (in house) objects don't always have the same guarantee of quality that (mostly) comes with commercial objects. Arbitrary deadlines generally exert a negative pressure on quality.

2. Feature creep. The initially simple and useful object is continually modified to add "just one more small but important feature" and with each new feature the object increases in complexity.

There's more to be said, but this is too tangential already.