 |
Managing Reuse |
Reuse was the hype upon which OT was originally sold but evidence of it actually being achieved was not that apparent. In fact, there was more evidence of OT having been abandoned because it had not immediately delivered the promised levels of reuse. However, it was clear that the claimed productivity gains were still attractive but were only to be gained from effective reuse. We therefore decided to take a closer look at how this might be realistically achieved.
The objective of the ‘Managing Reuse’ project was to address the questions :
- What reuse level is desirable and practically achievable over the next 3 years ?
- What should I do to enable it ?
This project addressed the whole life cycle, corporate IT and project management issues, library management and co-existence with legacy systems. It also suggested and provided guidance on a number of routes for achieving effective reuse, and was substantiated by supplier and IT user experiences between ‘92 and ‘93.
The main management issues we gathered from our member companies were concerned with :
- Whether reuse was essentially a business.
- Evidence of successful reuse.
- Scope and type of reuse found in practice.
- Enabling reuse and the role of the librarian.
- Project management.
- Quality.
- Methods and tools.
- Sub-contracting and out-sourcing.
- Legacy code.
- Costs.
- Metrics.
Reuse as a business decision
Effective reuse will not be achieved by developers or analysts
working in isolation. It requires the cooperation of all those
involved in the software development process. Neither will technology
alone produce significant reuse. This will only be achieved if
the business is involved as well. In reality, a mixture of technology,
business, commitment, infrastructure, management, tools and education
is required.
Evidence of successful reuse
It is now evident that most OO practitioners are starting to actively
address reuse. Members are handling reuse well, but cautiously.
They are aware of the barriers, such as the investment required
to ensure an adequate infrastructure is in place, but they are
not ignoring them. Instead, they are actively addressing the
barriers by, for example, starting to try and develop a suitable
reuse infrastructure on a small scale, while continuing to build-up
their experience of meeting real project demands and thereby increasing
the penetration of OO throughout their companies. In this way,
they are actually starting to see some of the benefits of reuse,
such as reduced maintenance effort (increased robustness), while
solving some of the problems, such as determining how to encourage
people to reuse. Using this approach, they are not immediately
achieving the dramatic reuse figures often publicised by suppliers,
but they are also not experiencing disastrous costs !
Scope and type of reuse found in practice
Members and other practitioners are now achieving reuse in applications
across projects and business areas, ie they are starting to see
corporation-wide reuse. With respect to the type of reuse being
achieved, most practitioners classify reusable components into
a number of categories. Although these classifications vary to
some degree, in general they include low-level technical, middleware
and business categories. The evidence from most practitioners
is that current success is confined to the technical and middleware
categories. Although, we are starting to see the emergence of
reuse in the business category, particularly in the telecomms
and financial dealing industries, where OO is more established.
Enabling reuse and the role of the librarian
Encouraging reuse involves effective communication and requires
an adequate supporting infrastructure for it to be enabled. Both
our members and the practitioners we met, have found that library
management, component development and tools for communication,
browsing and testing are all essential parts of an effective reuse
infrastructure.
The key tasks of library management include reviewing projects,
encouraging the development of generic requirements, helping to
identify potential reuse candidates, testing, version control,
raising awareness of library content, and any changes, standards
monitoring and inclusion, maintenance of metrics and administration.
That is, the people involved in library management are chiefly
responsible for promoting and enabling both the development and
use of components. For this to be done well, members and other
practitioners have found that high-profile roles, where these
tasks are their main responsibilities, need to be established.
At the start, or on small projects, it may be possible for these
roles to be part-time, but as OO penetration increases, they need
to become full-time librarian roles. Furthermore, once reuse
extends beyond the project level, members have also found they
need a corporate librarian to focus on components with corporate
benefit, by liaising with the various business areas and project
librarians.
Project management
The conventional culture of most IT divisions mitigates against
reuse. Project managers are rewarded for delivery, they are not
rewarded for reducing colleagues’ costs and timescales.
New approaches to organisation, costing and reward systems are
needed to change this culture.
The key objective has always been to deliver on time, within budget.
With OO, it is necessary to realise firstly that there are now
two deliverables - the application itself and the component library
- and secondly that there is an additional objective - to make
the most of reuse. To do this, the project manager needs to understand
the different skills required in using and developing components,
as opposed to building applications from scratch. This requires
considerable coordination and communication, and while this is
relatively easy in small teams, it is much harder in large teams.
This is eased by the existence of a project librarian, as long
as the project manager clearly establishes the role and coordinates
the interaction of the librarian with the rest of the team.
Quality issues
Members have found that the reuse of poor quality components should
be avoided at all costs, as it quickly demoralises staff and impedes
the shift to a reuse culture. Good quality components take a
considerable amount of effort, so being able to buy in good components
is seen as very attractive.
Methods and tools
A reuse culture places different requirements on supporting methods
and tools. Ultimately, methods and tools are needed which support
a ‘construction-by-component’ approach (including component
browsing/selection and reward/enforcement systems), iterative
development, configuration management and version control. But at the time of the project
no methods or tools adequately supported any of these.
In fact, there were very few tools specific to reuse and those
which were available were still immature. This included any communication
tools and reward/enforcement systems, the lack of which emphasised
the need for full-time, high-profile librarians, who in many cases
had to carry out these tasks unsupported.
Source control systems, such as SCCS or RCS, were used to help with version
control, but their use was neither elegant nor simple. A number
of browsers were available, but most operated on an inheritance-like
basis, which many practitioners found wasn’t the most
natural way to search for components. At the time they felt that
potentially basing browsers on, for example functions, relationships,
categorisation or prospecting might be preferable.
The PARTS Workbench from Digitalk, went some way to providing
a visual metaphor for ‘construction-by-component’, but
at the time of the project was not suitable for a large number of components.
A significant tool development at the time was Hitachi’s Object
Reuse Librarian (ORL) which provided the library developer with
integrated version control, version-history browsers, hypertext
authoring and guidance for reuse. They had also included some
of the different approaches to browsing.
The best choice of tools seemed to be for
Unix and the most limited for OS/2. We felt that many of these early tools
would not survive but at least they offered an interim solution as long
as any investment in them was carefully considered. However, in our opinion many
more tools were needed which supported reuse specifically, either
from the management perspective or the developer’s perspective.
Sub-contracting and out-sourcing
With sub-contracting and out-sourcing it is even more important
to realise that there are two key deliverables - the application
itself and the component libraries. These libraries are essential
to the continued evolution of the application as well as related
applications. They must therefore be built to a standard from
which continued component evolution can take place (possibly in-house)
at reasonable cost. This issue needs to be handled up-front at
the contract negotiation stage, as members have found that realisation
and re-negotiation half way through can be very expensive. The
issue of ownership of libraries also needs to be clarified.
Most of these issues still exist when sub-contracting is not
involved, but re-negotiation is not as visible.
Legacy code
In a number of cases, legacy code was being reused by regarding existing
systems and databases as large objects. This was enabled by ‘wrappering’,
that is by defining object interfaces to the legacy code so it
is effectively encapsulated.
Costs
Evidence we collected suggests that reusable components require
two to three times the effort to develop as an application-specific
solution. However, given that this includes trying them out in
at least three applications to ensure their quality, it ought
to be possible to defray the cost, across applications and possibly
projects. But this again requires a culture change and supporting
infrastructure. Members and practitioners’ early evidence,
however, suggests that this up-front investment in good reusable
components will ultimately save money on development and maintenance.
The librarian roles are also a perceived as additional costs.
But the members and practitioners who have established the roles,
all found that their existence had in fact proved cost-effective.
This was because the librarians had been able to prevent unnecessary
class development, while improving the overall standard of code
reliability and documentation, ultimately resulting in cost savings.
Metrics
Metrics were not readily available at the time of the project. Practitioners seemed to vary
considerably in their opinion about the true value of metrics,
but members in general had found a need for them. The key metric at that point was believed to be
the percentage of components being reused, so that
a continuous check could be made on the cost and worth of library
investment.
Concluding remarks
Evidence from our members and visiting practitioners showed that while a company is new to objects it is better to get a few successful projects up and running. Reuse can then be considered in subsequent, preferably related projects, in light of experience gained from the initial work. But at this point it requires serious consideration because for reuse to be effective it needs everybody’s commitment.
Reuse involves good communication and encouragement, and to enable this a proper infrastructure is absolutely essential. This needs to include librarian roles and appropriate tools for browsing, communicating library content and change management.
The benefits of reuse derive from reducing development effort, greater
software robustness and less maintenance and enhancement effort. This was supported by both our own members’ and external practitioners’ experiences.
But the necessary mixture of technology, business, commitment,
infrastructure, management, tools and education to achieve effective
reuse does cost ! On the other hand, doing nothing could mean over 200
man-years of OO code that needs re-engineering. Overall, the longer-term potential benefits were considered to exceed the costs.
In conclusion,where reuse is being tackled effectively, a comparatively cautious approach is being taken. Expectations are sensibly constrained while the level of OO experience is raised, organisational management and an adequate infrastructure are developed. On average it is taking around three years for the benefits to outweigh costs, but thereafter the productivity gains are significant.
Created : 30th April 1996
Updated : 11th August 1996
|
