The Development Framework Proliferation

Frameworks allow reuse of tried and tested software components, support the age-old IT mantra of "do not reinvent the wheel", and offer hope of the Software Engineer's holy grail of the perfect balance between reuse and a community based development approach. Naturally, there are pitfalls on the way to this nirvana and there can be a price to pay for over reliance on frameworks. Development projects can be overexposed to defects and poor performance in large, complex, unfamiliar and externally controlled code libraries. Projects that use third-party frameworks as key architecture components can unwittingly inherit the inevitable restrictions in their functionality and flexibility; a risk that is multiplied when a variety of different frameworks are in use. Similarly, there may be little option but to adopt changes in the architecture, or interfaces, of framework dependencies.

Although sometimes still considered controversial, it can be argued that any standard is better than no standard; consistence is better than inconsistency. In many development teams much time is routinely spent selecting and publicising architecture patterns. Imposing best practice on a team of skilled, and often very experienced, Software Engineers, is no mean feet. It is normally a lengthy uphill struggle to coax a group of, rightfully and justifiably opinionated, proven professionals, into conforming.

Frameworks can be used to enforce standard approaches and design principles without the almost inevitable, and all too often endless, debate over the relative merits of one approach over another. The fact is that, in any substantial software project, any architecture pattern will represent a compromise based on a mixture of the known requirements and anticipated future direction of the project. In these circumstances, a combination of the application of experience and good old-fashioned judgement, is what is needed.

In the wider IT industry, there is a tendency for a framework to grow in scope and complexity as user numbers increase, and demands for a evermore functionality are bowed too. This can result in many different frameworks becoming a niche skill in their own right and diluting the skills base of the industry by making Java development less broadly applicable as a skill. Of course there are winners and losers in the creation of specialised skills. However, I believe that innovation is also a casualty of this specialisation because companies find it more difficult to recruit staff due to the need to find a very specific set of skills, and find it difficult to change direction due too a designed or evolved reliance on third-party frameworks.

Further Reading: Design patterns : elements of reusable object-oriented software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.