Original URL: https://www.theregister.com/2006/01/24/framework_project_management/
The 'f' in framework
Now we know what it stands for ...
Posted in Software, 24th January 2006 11:47 GMT
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?
The first mistake was imagining that because the objects had some common attributes, they were related and should share an inheritance tree. Unfortunately, this is another case where software is not real life. Just because we put entities in the same box in reality, it doesn't necessarily follow that the objects representing them in a computer system share a common hierarchy.
The OO design principle that covers this is the Liskov Substitution Principle (LSP), which Bob Martin expounded in his programmer's notebook and also his book Agile Software Development. It states, "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it."
The example he gives is that of the square and the rectangle. In geometry, they are both two dimensional figures with four sides and four 90 degrees angles and square is a just a type of rectangle in which the height and width are equal. Obviously, it makes sense for square to derive from rectangle. However, under certain circumstances, squares and rectangles exhibit different behaviour. Change the width of a square, and its height changes too; otherwise it is no longer a square. Clearly any method that changed the width of the rectangle base class would also need to know about the special case of the square, thus breaking the LSP. The breakage tells us that, in this context, the square should most definitely not be derived from the rectangle.
Bob's point is that we naturally classify things using the ISA relationship, i.e. a square 'is a' rectangle but we should be classifying them using the 'behaves as a' relationship. Does a square behave as a rectangle? Well, as we've already seen, there are circumstances when it doesn't.
The second error is imagining we can predict the behaviour of objects before we build them. It's a bit like building a picture frame without measuring the picture first. We merrily set about developing a framework to manage our family of objects having arbitrarily decided they would behave in the same way. It's only after we finish the framework and start coding the objects themselves that we realise this is not the case. This means that every time we add a new object, we have to go back and change the framework and sometimes change all the other objects too, in order to accommodate the changes to the framework.
The third, and greatest error, is that as soon as the word framework arrives, the concept of business value disappears. The focus of development often becomes how to make the framework as flexible, extensible and future-proof as possible rather than how to deliver the customers' needs as quickly as possible. The 'F' stands for forgotten customer.
Don't get me wrong, I don't hate frameworks. There are many that I use on a daily basis and I have worked on many good ones myself. Indeed, most systems and applications contain frameworks of one sort or another. I would just like to remind you all of the three major errors listed on this page:
• Customers very rarely ask for, or are interested in frameworks; most customers want demonstrably working functionality.
• It is difficult, if not impossible, to predict the behaviour of objects in an environment before constructing and using them. It is far better to build and test the external behaviour of your objects before trying to identify their commonalities and building a framework to manage them. Automated refactoring makes this a relatively straightforward task in most environments.
• And, above all, don't be fooled by thinking that just because items share attributes, they will necessarily share behaviour.
Anyway, I know what I think the 'F' in framework stands for! ®
Related link
Buy your binary t-shirt at Cash & Carrion.