Over a million developers have joined DZone.

Building Frameworks For Internal Use

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:

Published at DZone with permission of George Dinwiddie, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}