Frameworks

• By Dwight Deugo
• April 24, 2001

Many people want one, but just as many people are not sure what they will receive when the box arrives. What am I talking about? A software framework. Rather than come up with my own definition—and I hope you see the parallelism in that statement with my editorial this month—let me give you one I found in the Dictionary of Object Technology. A framework is "any set of prebuilt classes and methods that define the basic structure of some end-user functions, leaving the application-specific details to be filled in by developers." The idea is that you purchase software that gives you most, but not all, of what you want. What remains for you to do is to follow the framework's mechanisms that let you create new classes or extend existing ones—such as by creating subclasses to implement methods that override methods of the superclasses—and then plug them into the framework. Sound easy? Probably not. However, the thought of developing from scratch what a framework can provide is not often worth the effort.

So, in addition to the code, exactly what are you getting with a framework? One of the most important items is wisdom. Any good framework provider will have already gone through the pain, agony, and mistakes of building a complete system without a framework before realizing one exists for the domain. I know many consulting companies that built systems for years before they realized they were building a portion of those systems repeatedly. It is only through experience—I don't see any other way—that the central issues can be faced, understood, and answered. I strongly believe you must live with the problems, create and use standards, and apply proven practices and patterns to be a good framework builder. These statements make the following questions important for you to answer before you build your next system. If it takes framework providers a long time to get their frameworks correct, how long will it take you to build a new system without one, and at what cost?

It's not difficult to argue that you can save money by purchasing a framework. For example, would it be cost-effective to buy an object-to-relational database mapping framework if one person's salary is $100K per year and the framework costs much less? Just think about how much development one person could do for such a framework on his/her own, especially with little knowledge in the area. I would also argue that you save time. To develop what a framework can provide is just a waste of your time. Don't forget about all the testing time that has been put into the framework on your behalf.

It comes down to this: Why build when you can buy? If I believe in a framework company, I believe in the software they provide. Like stocks, if you buy into something that has nothing of substance, you will get burned. However, good companies will generate great returns on your investments!