Commercial software houses often make use of development frameworks for a number of reasons, including; improved productivity for common requirements, improved reliability due to reuse and refinement, adherence to a conforming architecture, consistency between projects and teams, and provision of core functionality. These frameworks may, in themselves, be commercial products supplied and supported by a third party, or they may be an in-house proprietary framework developed to meet the specific needs of the software house. This article is going to discuss the relative merits of the latter.

One of the downsides of such frameworks is that there is inevitably a steep learning curve for new developers, who will be familiar with the language and syntax, but not with the code libraries, patterns and architecture. An additional drawback is that documentation is inevitably limited to that produced internally, which may vary considerably in availability and usefulness, and there will be no existing online training resources. It is therefore important that the company makes appropriate investment in documentation, and initial & on-going training. This should be targeted at both developers and analysts, as the framework will impose guidelines and restrictions on the technical specification as much as the actual development.

Furthermore, the use of a framework may be considered to stifle developer creativity and dramatically reduce the "palette" of technologies available for use in any given solution. However, it must be borne in mind that one of the primary objectives when adopting a framework is to gain some commercial advantages, which include encouraging development within a rigid architecture, and using specific patterns. It is intentional that the framework should remove some of the scope for creativity and originality, encouraging all company developers to code in the same, familiar way. Whilst a more relaxed approach may increase productivity initially (as a specific developer utilises some new feature of .NET, or some exotic new component or syntax), it will soon become counter-productive as other developers have to pick-up, and work with the exotic code. The ability to shift projects between teams with minimal "getting up to speed" time has important commercial benefits.

During the specification phase, it is inevitable that conflicts will arise over the availability (or not) of framework features to meet specific business requirements, but it is probably "healthy" (and potentially more profitable) to push back against new framework feature requests when existing functionality may be suitable. In this sense, a framework may also stifle the creativity of the analyst. By examining new requests "vigorously" the framework manager can be sure of separating out those that are really necessary, from the "nice to haves", and can focus resource on those features which will bring maximum business benefit. "Real World" project team and analyst input should be sought when designing new framework features.

A typical feature of development frameworks is the inclusion of a database persistence layer which automates the persistence of data from the application layer to/from the database. More advanced persistence layers may be Object-Relational Mapping tools when the framework is object-oriented. Such persistence layers inevitably cannot produce SQL statements to the same level of optimisation as a skilled developer could "hand-craft", but a mature framework will reliably build accurate statements automatically for any number of screens in a given system, saving a lot of manual coding time, and eliminating the potential for mistakes in hand-built code.

Given that one of the goals of a development framework is to promote consistency in architecture and patterns, it is important that the framework has an "owner" (individual or team), whose role it is to maintain & enhance the framework, and to contribute to the design of new systems to ensure the adoption of best practice. Keeping the framework up-to-date, and enhancing it with new features on a regular basis, are both important factors in encouraging "buy in" from all concerned. To this end, contributions from project (non-framework) development teams should be encouraged and actively supported, particularly in the design stage of a new feature when it is important to ensure it will meet the guidelines for the framework when built. Using features of the development IDE (such as "shelve-sets" in Team Foundation Server) can enable development teams to make changes and propose candidate features within the framework codebase, but without affecting other users, until the candidate has been approved and checked in.

Overall, we believe that the benefits of a proprietary development framework outweigh the disadvantages. As a framework matures, it will gain more and more stability, reliability, robustness, optimisation and features. It is therefore advantageous to "stick with" the chosen framework as far as possible in order to capitalise on the investment which has been made over time: the more widely it is used, the more benefit it will bring.