Agile Zone is brought to you in partnership with:

George Dinwiddie is an independent software development coach who helps organizations, large and small, to increase the effectiveness of their software development efforts. He provides guidance over a broad range, at the organizational, process, team, interpersonal, and technical levels. He is currently crusading to break down the barriers that hinder effective collaboration between the business, the programmers, and the testers. George is a frequent speaker at Agile conferences. George is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Building Frameworks For Internal Use

07.29.2013
| 2695 views |
  • submit to reddit

Suppose you have a number of products, or a number of applications, that share some common functional needs. It seems obviously reasonable to create a separate team to build those functions in common. Often these grow to become known as a framework, and the product or application teams are expected to use it.

It’s a seductive concept, but don’t do it. Why not? I can think of several reasons.

The first is that good frameworks aren’t built before being used. Instead, they’re extracted from successful products or applications. For anything of size, there are bound to be subtleties that you won’t get right until you try it for real. If you’re building a framework first, you’re delaying that first real trial. If the team using the framework is different from the one building it (as things are usually arranged) there’s significant delay for improvements needed by actual use. And that assumes the application team knows that the framework could and would be modified to accommodate them. Most often, they’ll just live with the problems.

Another reason is that your framework will never justify its cost as an internal product. When frameworks are built for sale, they have a large customer base depending on them, or they go off the market. Internal frameworks do not have that large customer base, and can never pay back enough to cover the inefficiencies of working that way. Instead, you’ll have taken the best and brightest of your developers for a framework that can’t turn a profit, starving your actual product of talent.

If you want to build an internal framework, build it from actual use. Put those best and brightest developers on the front lines of customer need, where they can do the most good. Distribute them among your application teams. Have them talk with each other, determining the common needs, and extract the framework as they go. They can act as Component Stewards, guiding the framework development and also guiding the use of it. They can then be in a position to know when the application should adjust to the framework, or the framework should accommodate the application.

Published at DZone with permission of George Dinwiddie, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Milos Silhanek replied on Wed, 2013/07/31 - 1:39am

Yes. Some framework is necessary but unreal to build it and very expensive without business value. When we began programming in cobol we tried some prototypes by old application and then wrote a specification for list-detail programme. Later when we used generator with its own templates it was great! But later we have to hack and modify some features (e.g. reading).

I have played with NetBeans Platform as an application base. I wondered what stuffs it does without my work. Right start, load, window system, resources, background tasks, actions...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.