I architected and wrote Java framework software and then used this framework to develop application software.  Eleven and one-half applications were implemented using such framework software (the "one-half" application was an application that was a hybrid which used another framework and non-framework code as well).  These applications were implemented in three distinct but related (through acquisition and partnerships) companies.  I was responsible for entirely coding five of these applications, the other applications containing anywhere from 0 to 70% of my code (in addition to the framework software).

Java programmers with a medium level of experience could generally do basic programming using the framework within a week, given proper training.  It took another week before the programmer could produce basic usable production code.  In the one case where somebody was trained to be a technical lead, it took about six months of mentoring before the person could lead a team to produce applications.  Thus, the framework, with about 200 methods, while non-trivial, was not too complex for programmers to learn.

The least complicated of the applications I wrote managed SKU's.  The most elaborate application combined sales force automation, credit approval and order entry functions.  It comprised 300 different classes (in addition to the base framework software classes) and over 300 HTML/JSP pages.  Besides sales force automation applications (5), the applications using the framework included an HR skills application, an installed base application, a document management application, the aforementioned SKU management application and two applications which were used to extend existing expense time-reporting systems.  The time needed to deliver the initial release of these applications ranged from two weeks to four months.

My first introduction to object-oriented programming came in the late-1980's.  However, it was only  in 1997 that I actually had the opportunity to direct application development using object-oriented programming.  This opportunity was especially valuable because I was able to implement object-oriented technology, learn from the implementation, adapt and change how the technology was used then go through the implementation-learning-adapting cycle again through 11-1/2 development projects.  My observations, based on this experience is:

• Using framework software, our team was able to reduce the amount of time required to develop applications by 70% (based on function-point analysis).  Obviously, this comes with a "your mileage may vary ..." caveat.
• Legacy applications present a different set of challenges as compared to new application development.  However, in the one legacy application conversion that I directed, our team was able to develop an application that reduced the cost of ownership of the application, increased customer satisfaction and was significantly cheaper than off-the-shelf applications that were being considered as an alternative.  The initial release of the application was completed in four months and was the first application completely written using my framework software.
• The amount of code used for repetitive non-application specific functionality is significantly reduced when using framework software.  As a result, programs were easier to debug and maintain.  This also reduced the amount of time that the expert programmers had to spend in discovering problems in less-expert programmers' programs.
• The use of a good framework promotes code consistency.  We had a good deal of programmer turnover, with 3-4 month durations not being unusual.  But we never had an issue with transitioning applications from one programmer to another as long the programmer being transitioned to was experienced in using the framework.
• The use of good framework software promotes reliable applications.  But these applications also strengthen the framework by exposing it to real-world usage.  This in turn strengthens the next application and the cycle repeats itself.
• During the application development process, it's not uncommon for the first version of any particular code section to be unoptimized, even if it is correct.  A good object-oriented framework promotes the use of common code.  This in turn increases the benefit-cost ratio to optimize the framework code.  Thus, the framework software, properly designed and properly developed over time will have (and in my experience did have) good performance characteristics.
• A major issue with some development organizations that I am familiar with was application development vs. maintenance staffing.  Programmers generally preferred to be on the new-development vs. maintenance teams and there was some organization friction between the two types of teams.  The use of a framework, along with other practices, allowed us to structure our teams so that a programmer generally was responsible for application maintenance after it was completed.  Because the maintenance (bug-fixing and minor changes) effort was low, the programmer would be able to spend the majority of his/her time on new development projects or on distinctly new functions in a production application.

The promise made in the 1980's by computer theorists regarding object-oriented programming has been fulfilled, at least for me.  Using object-oriented framework software, we consistently delivered cost-effective, high-quality applications to our customers on a timely basis.  It's not easy and the road to application development nirvana is littered with the remains of many failed object-oriented development projects.  But it can be done.  Take it from somebody who's been there.

General Overview

Technical Overview