<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

The horse and buggy is still a viable mode of transportation. Newer needs can be accommodated by adding horses and modifying the buggy. Of course just because something can be done doesn’t mean it should.
When Java was establishing itself as a staple of modern enterprise applications development teams began creating frameworks for standard needs. Two of the more common types of frameworks handled views and persistence. Though these teams worked independently for a variety of companies serving the needs of a wide range of domains, many of the frameworks grew to be very similar. It was only natural that attempts would be made to standardize these commonalities as developers moved between companies and compared notes. Through this organic process common frameworks such as Struts and Hibernate became staples of enterprise development.
It is pretty much a given that new enterprise applications will use standard frameworks. But what about applications birthed in the time before these standard frameworks? This is where things get complex. Refactoring an existing legacy application with five to ten years of stability to use newer frameworks is a difficult proposition. The process is expensive in terms of cost, time and resources. Oft times the final application will not be noticeably different to the end-user. The mentality of management is normally "if it ain't broke, don't fix it". This is the appropriate sentiment when the application will continue to exist in a pure maintenance mode for the rest of its lifecycle.
The complacency inherent in remaining on legacy frameworks can be the death knell for applications that will continue to change. There are a number of factors which come into play here.
The first, and most important, peril is the loss of developer knowledge of legacy frameworks. Over time any development team will be subject to developer attrition. As developers leave knowledge of the legacy framework functionality dwindles. In a perfect world there would be sufficient documentation for other developers to understand how legacy frameworks function. This is seldom the case in practice, however. New developers tasked with filling the roles of departing team members often find it difficult to get a full handle on the capabilities and idiosyncrasies of the legacy frameworks. This becomes a drain on the productivity of new team members.
A second danger closely related to the first is one of staffing. How do you replace team members or add more members to the team? With standardized frameworks this is a simpler proposition. If a team needs a developer familiar with Struts they have a larger pool of potential candidates. More documentation and examples exist for more standardized frameworks exists, giving new and existing team members better resources for proper framework application. In addition to the larger candidate pools, teams can staff with less experienced developers, providing a general cost savings. Legacy frameworks often require the addition of veteran developers who have more experience in the older technologies that formed the original foundations of the frameworks. These developers are normally more expensive to hire and found in very short supply.
Another danger in clinging to legacy frameworks is the number of “hacks” added to the frameworks to add new functionality. Over time these modifications build atop one another. They may break previously working functionality. They may result in performance degradations. They also commonly result in increasing complexity in the addition of subsequent functionality, increasing development time and cost.
A fourth hazard is the inability to leverage newer technologies because of the constraints of legacy frameworks. A prime example of this is the increasing shift to mobile content delivery in the enterprise space. An application with a legacy view framework may not have the flexibility to deliver content to new devices. This can quickly render a leading solution from a decade earlier irrelevant in the face of newer applications with more flexible frameworks. Even if a legacy framework can be adapted to newer technologies, the change may not be able to be accomplished before more nimble competitors gain a foothold.
Is moving from a legacy framework to a new framework always the correct decision? No. If there is no intention to add functionality to an application or if the end of life for the application is in the immediate future it often doesn’t make sense to invest the time and resources into a refactoring effort. However if the application is considered a core business component with an active development lifecycle it is often a necessity to start incorporating newer frameworks. The longer such efforts are more delayed, the greater the difficulty, cost and danger to the business become.

See More From These Topics