Saturday, May 26, 2007

Is Your Framework Adding Value?

Trust me, this is going somewhere...

Pre-fab or Field-fit?

A friend of mine is a drilling engineer. He has traveled around the globe and has many interesting stories he has shared with me. One involved an experience he had while working in the former Soviet Union around 1993. He and some co-workers toured a factory where pre-fabricated apartments were being built. The idea was that the major components, such as walls, would be built in the factory and trucked to the site where they could be assembled, simplifying the construction process.

Sounds great in theory, but my friend noticed a flaw in the implementation. The walls were made by pouring concrete into large rectangular wooden forms. These forms had internal forms for windows. While the forms were precisely measured and designed to fit, the corners of the internal frames were not braced and as the concrete was poured, they shifted, and what should have been a rectangular shaped window in the middle of the wall wound up being a parallelogram with non-right angles for corners. What should have simplified construction in the field wound up creating more work than starting from scratch, as each section had to be "field fit".

When asked about the problem, the factory workers shrugged and indicated that since it wasn't their problem, they didn't feel any need to change what they were doing. Of course, it didn't matter, since the window glass never fit anyway. When they assembled the buildings, the panes of glass were often overlapped.

The Liquid Foundation

While watching the History Channel, I saw an interesting program about an earthquake in Kobe, Japan in 1995. It turns out that the Japanese have taken to creating artificial land to help ease the real-estate shortage that they are experiencing. This is done by dredging soil from the ocean floor and depositing in other water-filled areas until it forms artificial land ready-made for the construction of houses, businesses, and highways.

Unfortunately, when the earthquake hit, an unexpected state change, known as soil liquefaction, occurred in this artificial land. As the shocks occurred, the land acted, for all intents and purposes, like a liquid, flowing and oozing all over the place. Anything built on top of this now liquid foundation was destroyed.

Software as Architecture

It is fashionable to compare the creation of software with the creation of buildings. We go so far as to call many members of the software industry "architects". While I am not crazy about this metaphor, it does work at times.

Software organizations often attempt to go the prefab route by building frameworks composed of common utilities that can be "trucked" to different developments. The thought is that the framework provides a pre-fabricated foundation (to stick with the metaphor) on which to build the application.

Sounds great in theory. Hmmm, where have we heard that before? At issue is the quality of said framework. Were the architects of the framework familiar with good API design? Were there any architects or is the framework simply an amalgamation of code fragments gathered from other developments? Is the goal of the framework to provide the basics or does it represent a grand attempt to boil the ocean? And most importantly, does the framework simplify application development or does it complicate the application and leave it with "window frames" that are field-fit and "panes of glass" that overlap?

These are important questions for a development organization to ask when it assesses whether to go the prefabricated framework route. Not only is there a risk of wasting development effort (and slowing time to market) trying to fit an application into an awkward architecture, but after this occurs, the resulting product is now built on a shaky foundation that may liquefy at any time, but of course it will wait to do so until deployed at a large customer site.

I am not saying that frameworks in and of themselves are bad. At issue is how the framework was constructed and whether it truly provides the value its use implies. We can look to the open source communities for examples of frameworks that work. Spring, Hibernate, Commons Logging... solid and designed for easy integration.

I told you I was going somewhere.

2 comments:

Chip Overclock said...

A very old rule of thumb (like, from the 1970s) is that a piece of software has to be ported and used in at least three different applications before you can csll it truly reusable. It always seemed pretty reasonable to me. I suspect this applies to today's frameworks just as it applied to function libraries in the 1970s.

mcjoe said...

The used three times rule is perhaps a necessary, but definitely not a sufficient condition.

The framework that inspired me to write this blog has been used in many projects, and each project must suffer through the pains of said integration. This is due to a combination of poor design and poor documentation.

I assure you that while the framework I refer to meets the requirement that you refer to, it is still far from reusable and still requires a lot of field fit to get it to work at all.