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.

Normalisation of Deviance

A prevailing attitude of "if it ain't broke don't fix" and "this is how we have always done it" encourages the delusion that there is no inherent risk in the process. The knowledge that "it hasn't gone wrong before" is used to support an assumption that there is no risk, and any suggestion to the contrary is dismissed as the paranoid ramblings of doom-mongers, pessimists and nay-sayers. Those who promote the current process, whatever it may be, without subjecting it to the rigors of subjective criticism, do so in order to establish the business-as-usual so as to maintain their perception of "smooth running". This lack of pro-active oversight, and lack of support to implement pre-emptive change, creates an environment that allows, and in-fact passively promotes, the Normalisation of Deviance.

There is often a tendency to dismiss concerns of this ilk as the eccentricities of the perfectionist; a mere striving for the unachievable. This would be true, if applied to a game of chance such as roulette. Engineering projects, like roulette and and all aspects of life, do contain an inherent level of risk. However, unlike roulette, it is possible to measure, mitigate and often protect against the most severe impacts of the risks associated with an engineering project.

The correct response to addressing these issues is to maintain constant vigilance, be prepared to review and adapt processes on an ongoing basis, and remain constantly open to accessing any-and-all feedback from those who implement the procedures. Those who take the time and trouble to provide feedback should not be thought of as troublemakers or, worse still, whistleblowers. Instead, such individuals should, until proven otherwise, be considered as diligent operators who's thoroughness can and should be valued as perhaps the last line in defence against the worst case scenario.