\markboth{Wasmund}{Wasmund}
%.cm Position paper for 6th SW Reuse Workshop, 1993.
%.*  Document owner:  M. Wasmund
\documentstyle[11pt]{article}
\oddsidemargin     -.26in
\evensidemargin    -.26in
\topmargin         -1.00in
\headheight        .00in
\headsep           .75in
\footheight        12.0pt
\footskip          25.0pt
\textheight        9.425in
\textwidth         6.50in

\markboth{Wasmund}{Wasmund}
\pagestyle{myheadings}

\parindent=0pt
\parskip=10pt
%
\def\@maketitle{\vbox to 2.6in{\hsize\textwidth
    \linewidth\hsize \vfil \centering
    {\large \@title \par}
    \vskip 2em
    {\normalsize
    \begin{tabular}[t]{c}\@author
    \end{tabular}\par}
    \vfil}
}

\begin{document}

%\bibliographystyle{alpha}
\bibliographystyle{ieeetr}

\title{Incentives versus targets - a practical experience}

\author{Michael Wasmund\\
IBM Deutschland GmbH\\
Schoenaicher Str. 220\\
W--71032 Boeblingen\\
Germany\\
Tel: (011)--49--7031--16--2273\\
Fax: (011)--49--7031--16--3545.\\
E--mail: wasmund@boevm4.vnet.ibm.com
}
\date{}

\maketitle

\begin{abstract}

Papers recently published about Tech transfer issues in the area of
reuse agree upon the following: The major obstacles in realizing the
expected benefits from reuse are rather related to human behavior than
to technical barriers. A very frequently discussed means to stimulate
desired behavior are incentives: Major companies established incentive
programs to stimulate reuse and consider this helpful particular in the
beginning stage. However, massive progress solely through incentive
programs is not reported. An alternative mode of stimulation is the
establishment of quantitative targets for reuse. Opinions differ on the
usefulness of mandatory versus voluntarily stimulations.

At IBM's system software development site in Boeblingen, Germany, we
had the opportunity to test both approaches. This position paper
depicts experiences with either approach. The result is that mandating
reuse targets significantly raised the level of practiced reuse in
general, but also generated some unwanted minor side effects.
\vspace{0.2in}
\noindent

{\bf Keywords:} Reuse, Incentives, Experience Report, Software Reuse, IBM.

\vspace{0.2in}
\noindent

{\bf Workshop Goals:}  Share experience about process modification and
 implementation. Learn how object-oriented techniques and reuse merge.
\vspace{0.2in}
\noindent

{\bf Working Groups}: Tech Transfer issues, Reuse \& OOT.
\end{abstract}

\newpage

\section{Background}

Papers recently published about Tech transfer issues \cite{joos92,wasmund92}
in the area of reuse agree upon the following: The major obstacles in
realizing the expected benefits from reuse are rather related to human
behavior than to technical barriers. A very frequently discussed means
to stimulate desired behavior are incentives \cite{Fairley89,Carstensen87}.
Major companies established incentive programs \cite{Cavaliere83,Hooper91}
and consider this helpful particular in the beginning stage of tech
transfer.
However, no one reports that incentives have caused an avalanche
effect, i.e., massive and broad change in behavior of addressed people.

Other reuse experts \cite{Tirso91} recommend a more mandatory
enforcement, i.e., establishment and monitoring of quantitative targets
for reuse by site management. Opinions differ on the usefulness of
imposing a desired behavior through targets in contrast to stimulation
of voluntarily moves.

At IBM's system software development site in Boeblingen, Germany, we
had the opportunity to test both approaches.
This position paper depicts experiences with either approach.
The result is that mandating reuse targets significantly raised the
level of practiced reuse in general, but also some unwanted minor side
effects. \medskip

\section{Position}
Prior to application of any methods to change behavior, we found it
essential to recognize inhibitors: The following technical inhibitors
are most often mentioned by tech transfer agents:
\begin{itemize}
\item Lack of reusable components
\item Lack of component compatibility
\item Lack of appropriate development environment
\item Lack of appropriate database retrieval mechanisms.
\end{itemize}

Motivating people to practice methods which are not technically
supported would render all tech transfer efforts meaningless.
Therefore, technical inhibitors must be removed or at least smoothened
before addressing the following often cited non-technical inhibitors:
\begin{itemize}
\item Lack of management commitment
\item Lack of long-term product strategy
\item Not-invented-here syndrome (NIH)
\item Lack of education in software engineering principles
\end{itemize}

Practitioners and tech transfer agents agree that 'lack of
management commitment' and 'Not-invented-here' are the major hurdles.
\subsection{Incentives}

At IBM, all major development sites applied incentive programs.
These programs are cheap compared to otherwise redundant software
development and reward desired behavior, particular removing the NIH
inhibitor.

There are basically two classes of incentive programs: Point-based
and not point-based. The point-based programs are set up similar to a
Frequent Flyer Program: The more 'reuse' an individual practices, the
more points are credited.
A certain amount of accumulated points qualifies for a (mostly
monetary) award.

'Practicing Reuse' means either using available components for
product development or it means production of reusable components
itself.
The latter is in most programs linked to the condition that the
produced reusable component is actually reused at least once in order
to justify the effort.

The other class of incentive programs (non-point based) grants
monetary or other awards to selected individuals or teams in order to
show and reward successful examples of the desired mode of work. The
criteria for this class of incentives are rather qualitative (e.g.,
innovative approach) than quantitative (cost savings, quality gains).

IBM Lab Boeblingen chose a non-point based incentive program.
The rationale for this decision was:
\begin{enumerate}
\item To avoid the overhead of calculating and managing accounts of
individual's points,
\item To avoid frictions between comparable individuals in assessing the
correctne ss of accumulated points,
\item To ease the opportunity to grant team awards as alternative to team
awards.
\end{enumerate}
\subsection{Impact of the chosen incentive program}

An instance of the non-point based class of incentive program has
been established in spring 1992 at our lab. The program was announced
by a personal letter of the area manager to all employees. In the
course of 1992, three applications for reuse awards were submitted, one
thereof was actually granted.

Analysis of the slim acceptance of the program showed:
\begin{enumerate}
\item The extremely tight schedule of product developments did not
encourage additional investments in making software reusable. Even if
someone did invest his private time in doing that, he would be eligible
for a reuse award only if a second user of his software could be found.
\item On the other hand, integrating reusable components into new
products should help in meeting tight deadlines by prevention of
redundant coding, particular in the area of general-purpose routines.
\end{enumerate}

However, there are some risks involved in integrating reusable
components from other sources:
\begin{itemize}
\item Time must be spent for searching the matching component, without
knowing whether a component will be found,
\item If a component is found, integration of the obtained component can
yield unsatisfactorily results not visible from the description
accompanying the component: Unknown bugs, interface binding problems,
runtime problems, performance.
\item Dissemination of object-oriented methods facilitating reuse was
just at the beginning. Very few people could enjoy an object- oriented
environment including class libraries.
\end{itemize}

Only few developers were willing to trade in these risks for the
chance of saving considerable coding - and maintenance - effort.
Most individuals would follow known and always practiced methods.

In summary, the impact of the incentive program was minor. It did
not change adherence to traditional development methods to a great
extent.
\subsection{Reuse Targets}

Realizing the slow progress, management decided in January 1993 to
mandate reuse by establishment of a formal reuse target of 20% across
the organization.
The targets were propagated down the hierarchy and even included in
some individual's performance plans.

The effect was an immediate jump in requests for reusable parts.
Fortunately, most requests could be satisfied, particularly by our own
unique parts center \cite{Lenz87} providing general purpose components
for abstract data types and class libraries.
The fact that now there was no choice for the professional but to leave
traditional paths in order to support the reuse target, and the support
of the management team, which also had the objective to utilize new
software development methods, literally changed the world at Boeblingen
Lab.
The ratio of reuse related activities 1992 to 1993 is close to 1:4.

\subsection{Side Effects}
The establishment of targets had generally a very positive effect.
However, we obeyed the following side effects:
\begin{itemize}
\item Some organizational units overdid the setting of targets by
prescribing each individuals quantitative contribution to the reuse
figures.
The opportunity to reuse available components greatly depends on the
technical contents of the work an individual has to do, so mismatches
between realistic reuse opportunities and set targets occurred.
In addition, the partition of the technical project content in pieces
can lead to very heterogeneous reuse results within a group. If each
group member has personal reuse targets, frictions can occur.
In summary, I do not recommend to define reuse targets more granular
than on 'group' or 'project' level.
\item Secondly, bad surprises caused by unprepared application of complex
reusable components came up at some places.
Some groups intensively embarked on practicing reuse immediately after
announcement of the targets without having had appropriate training or
other preparation. This lead to severe problems during the coding
phase, because the design originally did not reflect that large amount
of reused software. It turned out, that the first application of reuse
took considerably more time than expected; heavy support by the
originator of reusable components was needed.

Learning from this, setting of reuse targets must reflect education
effort in order to effectively apply new methods rather than to 'jump
into'.
\item Another side-effect was caused by flat undifferentiated application
of the same reuse target across all departments regardless of the
department's actual task. There was a sound definition established for
reuse of {\em software }  \cite{Poulin93c}.
However, other operations such as Information Development and Test, had
problems to apply reuse targets on their business, without support of
established measurements.
Subsequently, there was great confusion, what the target means and how
achievements of different operations contribute to the reuse results.
\item Last but not least, some individuals tried to enhance their
personal reuse result by integration of extra large reusable
components, whose whole function set was not really needed.
\end{itemize}

Despite these non-neglectible side-effects, the comparison between
1992 and 1993 shows a crystal clear preference for introduction of new
technologies through establishment of sound quantitative targets.
\section{Comparision}
It is the objective of this position paper to convey the lessons
learned.
The definite preference statement made above applies to our specific
organization. Other organizations may react different to the same set
of motivators. The history, composition, and mission of an organization
heavily determines its reaction to different tech transfer approaches.
Our organization is characterized by a major amount of legacy code
maintenance and enhancements, a major amount of assembler code, and
some progressive projects using object-oriented technologies.
The average age of our professionals is 40+ years, which also makes a
difference. I think, these are important attributes to know in order to
assess the applicability of the position made in this paper.

\bibliography{wasmund}

\section{Biography}
{\bf Michael Wasmund} {\em IBM Germany,Dept. 3238, Schoenaicher Str.
220, W--71032 Boeblingen,} is Site Reuse Champion at IBM's system software
laboratory in Boeblingen., focusing on implementation of a reuse
methodology throughout product development.  Previously, he was research
staff member at IBM's European Networking Center, Heidelberg, Germany,
where he published several papers about networking in heterogeneous
environments. At the beginning of his IBM career, he developed IEEE
802.3 adapters for S/370 series.  He obtained his B.S.E.E. and M.S.E.E.
degrees in Ulm and Bremen (Germany), respectively.

\end{document}
