ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr7/proceedings/txt/ylarotiala.txt

Text File | 1995-08-13 | 14KB | 252 lines

How to convince the management?

Aarne H. Yla-Rotiala

Nokia Telecommunications
P.O. Box 33
02601 Espoo, FINLAND
Tel: [phone]
Email: [e-mail]

Abstract

Software reuse is a way to increase productivity and to get better quality.
It seems that reuse is often stated as a goal for improvement programs,
and that companies and other organizations feel the need to "do reuse".
The order of steps is not predetermined, but then by keeping the actual
goals - productivity, product quality, customer satisfaction - in mind one
is able to travel towards a better software engineering solution. By
improving the organization's state of the practice it is possible to finally
stumble into reuse, but without having to bleed in the process. Doing the
improvement in a planned manner with centralized resource allocations
could be in some way more efficient than this Darwinian path, but the
effect on customer-oriented and financially responsible units within a
company can be negative. The conclusion of this presentation is that "It
looks like having reuse as a goal is having the wrong goal", especially
from the management perspective. The conclusion is followed by the
question "What is wrong with this conclusion?".

Keywords: Quality, productivity, investment, management.

Workshop Goals:Practical experience exchange, counter arguments
against my position.

Working Groups: Tools and environments,Software engineering
management and economics

1   Background

I have been a practicing software engineer for several years now. As such,
I have gotten more or less acquainted with several methods to achieve
better quality and productivity. Among these methods, reuse has been
and still is one of my favorites. During my active career I have written
and used (re-)usable components, and tried to get a grasp of what reuse
is all about. So far I am in the wilderness: there seems to be little
difference between "Solid Software Engineering" and "Software Reuse".

2   Position

Motorola [1] and IBM [2] have documented successful reuse programs.
These and other efforts like STARS are specificly aimed at enhancing
reuse in the organization's software engineering process. This requires a
lot of management support and commitment, up to the CEO level.
Investments are huge, and the pay-off time is usually several years.  The
positive effect of such a program is "enhanced reuse" and "better
reusability"of the software products created in the organization.
Eventually this is believed to result in lower overall costs, better quality
and shorter time to market for new products, which are all desirable
goals. These goals - and other similar ones - are what companies are
actually looking for when they launch "quality", "productivity" or even
"reuse" programs.

Given the time-scale and investment required to start and run a
successful reuse program , it is not very likely that the average manager
is willing to authorize such a program. If the program's goal is set to
enhance reuse, the connection between the bottom line - or harder-to-
measure things like customer satisfaction - is very fuzzy at best. Fast
programs with more concrete goals are likely to be easier to accept.
Expensive initiatives that take years to complete should not focus on
only one aspect or method to achieve better quality and larger profits,
but on a holistic approach to the company's software engineering process
and environments. The chain of deduction should go the other way
round: Do something for better abstractions, create better tools, enhance
communications, educate the engineers and preach about usability on
all levels of you process and product, and eventually you'll get better
quality, faster throughput, larger profits and even more (re-)usable
software and more (re-)use of existing artifacts. My position is therefore
that "reuse" is actually a synonym for several "Good Things" in Software
Engineering, and that many software engineers and managers see it that
way, and that to achieve these "Good Things"  ne should concentrate on
good software engineering process and methodology improvement in
general.

2.1  The Case of Nokia Telecommunications

The above position stems from a few observations made at Nokia
Telecommunications.There has been an ongoing discussion about "reuse"
and the necessity of it, which actually seems to have blinded us from the
fact that in a sense we are already there.

NTC's DX 200 product's internal architecture has been under scrutiny,
and the results are being implemented. The product - and the
organization - is organized into several platforms of different abstraction
levels. New enhancements to common platforms are made partially by
applying a standard procedure for generalizing specific features created
initially for a narrow or even a customer-specific purpose. Different
system and code generators have been built over the years, and the
abstraction level for the average softare engineer is continuously getting
higher and higher. All these - a common repository or a "platform"and
the higher level tools - have been initiated as more or less independent
projects. The end result from this drive towards clear goals is actually
very similar to what is the cookbook approach toward reuse 1 . This is
the observation that deserves some attention, since the word "reuse" has
been mentioned only in the context that "we should be doing it", and
usually it has been found out that "in a sense, we are already doing it",
which revelation leads to either the conclusion that we are not doing
enough or to the question about "where is the beef in reuse - do we need
to think about it any more".

The way process and methdology enhancements have usually started is
that there has been a clear idea of what should be done and what
benefits the improvement would bring with it. Thus, on the road to the
current situation,the motivation has always been something else but
reuse - better quality, better productivity or whatever. In the tough
competition there seems to be little or no room for two-phased
improvement paths forcing the organization first to invest to reach an
intermediate state of "Great Expectations", and from there to proceed to
financial success. It is possible to justify and start large investments with
long pay-off times if the benefits are clear and large enough, but it seems
unlikely that such investments can be done if the promised benefits
have no direct consequences in the company's competitiveness. For this
reason reuse should not be stated as a goal for an improvement program,
and no company should make the error of believing that "doing reuse" is
the goal of any of its actions 2 .

2.2  Planned company-level reuse can be bad for the company

Some successful companies - including Nokia 3 - try to avoid too much
centralized control, and favor more or less independent business units
with clear customer-orientation and local authority for all business-
related issues 4 . The business units are given responsibility of their
customer accounts and products, they have precise profit goals, and
therefore they have a large amount of authority. This implies that a
company-wide program that affects the software production technology
and the software engineering processes in the profit centers could disrupt
the operations of the units. If a large-scale program is to be started, the
program should be accepted both in the headquarters and in the units.
Since the units usually have slightly different short-term and long-term
goals, creating an agreement of what should be done, who pays for it and
how much effort should be put in can be difficult.

All this implies that large-scale reuse programs can be hard to start in
some business environments. The necessary "CEO support" - or, at
business unit level, the "unit manager support" - means that the CEO or
the unit manager should start interfering with the operations of the
units or the departments, which implies that the management
philosophy has to be more or less centralized. If not, interfering with the
local authority can disrupt the smooth local operations,which is usually
not a good thing. In exceptional cases it can be done; for example, a
quality system and the ISO9000 approval must be a company-wide
effort. Implementing a similar program for an individual technique or
set of techniques like reuse in the corporate level is somewhat unlikely
since a corporate program interferes and disrupts the operations of the
units, and therefore breaks the corporatemanagement culture,which is
usually much more valuable than an independent implementation-level
technology. In the unit - or "domain" - level such a program is easier to
start, but the acceptable amount of resource expenditure is naturally
much smaller. That means that investments are smaller and that the
technology to be used must scale down, too, and that there should be a
mechanism of building software engineering infrastructure in general
and reuse technology in particular at least partially in a bottom-up
manner.

_______________________________
 1 Spend time and resources to get large common building blocks for
application developers.Build system generators if you can. Take care of
communications and quality control.
  2 Excluding companies that try to sell reuse, naturally.
  3 The CEOJorma Ollila has publicly stated that he is very happy with
the distributed decision-making in the group and finds it a valuable
asset.
  4According to the sales people of e.g. Hewlett-Packard, HP has similar
attitude towards local versus centralized decision-making.

3   Comparison with other work

This position seems to contrast the positive results from e.g. IBM and
Motorola.  The described improvement method has a similarity with the
Capability Maturity Model [3]. The difference can be only a superficial
one: what has been said here is that the goals and motives for doing
improvements should be suitable for the organization and that the goals
should offer something measurable. This is in no contrast with what has
been said in earlier work. On the other hand, the concept of having reuse
as a goal for an organization is not believed to be universally true. While
it is OK to have e.g.  reuse as the initial theme for improvement, the
goals should be connected to the company's business improvements.
While the benefits of reuse programs cannot be denied, questions and
doubts about the overall efficiency arises, and alternative what-if
scenarios 5 would be very welcome to clarify the issues.

[4] attempts to explain the problems IBM faced in the computer
industry after the introduction of the IBMPC. The given explanation can
be argued, but the authors continue to describe a "Silicon Valley model"
of high technology management, which emphasizes fast actions,
concentration on the core competence and architectural domination of
the market. The model includes emphasis on loosely coupled small
organizations with well defined interfaces, which means distributed
control and command. The text implies that such an organization is
"goo d", and claims that the pace of technology requires it or some other
adaptive and slick organizational model. True or not,the Ferguson's and
Morris's arguments have a similarity with this presentation,and it would
indeed be hard to devise a way to implement a long-range reuse program
in a fast setting they describe.

The work about e.g. system generators [5] and other implementation
level reuse technologies is in no contrast or agreement with this
observation. The issue here is why and how should one run a reuse or
other process improvement projects, not the actual steps in the potential
projects.

Work and opinions about Software Process Automation [6] are
compatible with my alleged observation. Goals need to be defined, steps
determined and results measured when one is trying to improve the
performance of the organization. What might be left unsaid is that the
organization needs to be aware of what it really needs, and should not
concentrate on secondary or technological issues, at least not if the
technology is not the business of the organization.

_______________________________5
Such scenarios are naturally error-prone, and prove little, if nothing.
They still present alternative lines of thinking, and are therefore
valuable.

References

[1]R. L. Joos, "Software reuse at motorola," IEEE Software, vol. 11,
September 1994.

[2]A. Endres, "Lessons learned in an industrial software lab," IEEE
Software, vol. 10, pp. 58-61, September 1993.

[3]M. Paulk, B. Curtis,and C. et al., "Capability Maturity Model for
Software," Tech. Rep. CMU/SEI-91-TR-24, Software Engineering
Institute/Carnegie Mellon University, Pittsburgh, Pennsylvania, August
1991.

[4]C. H. Ferguson and C. R. Morris, Computer Wars. Times Books, 1994.

[5]D. Batory, V. Singhal, J. Thomas, S. Dasari, B. Geraci, and M. Sirkin,
"The Genvoca model of software-systemgenerators," IEEE Software, vol. 11,
September 1994.

[6]A. M. Christie, Software Process Automation. Springer-Verlag, 1995.

4   Biography

Aarne H. Yla-Rotiala is a software engineer at Nokia Telecommunications.
He works at the software engineering department, and is currently
involved in a project that is developing the software engineering
environment in use at the development of DX 200 software. He received
a M.Sc from the university of Helsinkiin 1990, and is enlisted as a Ph.D
student at the department of computer science.