The 'f' in framework

Now we know what it stands for ...

Comment There are but 10 types of people in the world. Those who understand the binary numbering system and those who don't. Sadly, I think that's probably the funniest programmer joke I've ever heard. Underlying it, however, is something that has important ramifications in the world of software development - the tendency for human beings to divide everything in the world into categories.

This tendency toward classification is not a bad thing and is, indeed, necessary. It is the very basis of inference. We need to have labels for groups of things so that we can make decisions more easily and make use of the inference engine we carry around in our skulls, the brain. If we classify foodstuffs into edible and poisonous categories it becomes much easier to say, "don't eat anything poisonous" than to list each individual poison in our warning. Similarly, we can define geographic locations as safe to visit or dangerous; fertile or barren; etc, etc.

It's not difficult to see the benefit of this ability and it’s part of our evolutionary make up, which is probably why we are always so keen to practice it even when its use is inappropriate.

You'll all be familiar with the situation at the beginning of a project, when the customer has outlined his requirements and we're discussing how to carve them into stories. It's just about then that someone opines, "The objects in this system all belong to the same category and must, therefore, form a class hierarchy". Then the dreaded 'F' word appears; "we need to build a framework!" is the cry, and from then on the discussion turns to what other objects will be required to interact with our class hierarchy. The next thing you know, we've moved onto design patterns and object models.

Interspersed with the talk of relationships and attributes are the promises of economies of scale gained by having all objects seen as equal by the framework allowing the same code to handle all cases and situations. The 'F' in framework stands for faster development, I've been told.

Promises of extensibility also abound, simply plug your new subclass in and the framework will manage it in just the same way it manages all the other classes in the hierarchy, because they are all related there are no modifications required. Future-proof and flexibility are what the 'F' stands for now.

Six months down the line though, we're wondering why our three-month project isn't finished yet. Each new piece of functionality takes forever, amendments cause so much pain and the whole team is demoralised, wondering how we got to here from our much-lauded framework. So now the 'F' stands for failure! Where did we go wrong?