The Business Objects
Real World Experience
Back to Framework Home
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
One big lesson that I learned is that it is possible to construct a usable
software framework without having to spend a king's ransom and without having
to seriously disrupt on-going application development efforts. Once
built, there are two big advantages that such a framework has over commercially
available framework software. First, a developer wants software framework
that is portable, flexible, extensible and easy to learn and use. On
the other hand, a framework software vendor wants to lock customers into
their framework software, wants to sell "extensions" to their customers and
loves to sell professional services to their customers. In other words,
I think that with framework software, the customers' and the vendors' goals
are less complementary than they are in other software categories.
Second, good framework software with programmers who can extend the framework
gives an application development organization the ability to respond to business
requirements. There were numerous occasions where we had to provide
specific functionality that wasn't general enough to include in the framework
but which needed to work with the framework. Once this functionality
was added, it was easily transferred to other applications using the framework.
- 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
- 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.