\markboth{Dusink}{Dusink}

\documentstyle[11pt]{article}
\oddsidemargin  0.26in % Leave enough for binding margin
\evensidemargin 0.26in %
\topmargin      -1.00in % (adjusted for printer bias)
\headheight      .00in  % (no headers)
\headsep         .75in  % (top margin + headers + skip)
\footheight     12.0pt  % ??? (seems to work ok)
\footskip       25.0pt  % ??? ( "   "  )
\textheight     9.425in % (instructions: 9 1/8" min, 9 7/16" max)
\textwidth      6.5in   %

\markboth{Dusink}{Dusink}
\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{ieeetr}

\title{Insight in the Reuse Process?}

\author{Liesbeth Dusink\\
\\
TU Delft\\
Tel: +31-15-783832\\
Email: betje@twi.tudelft.nl\\
}
\date{}

\maketitle

\begin{abstract}

In this paper I take the position that at this moment we do not have
insight in the software engineering process
and as reuse is a software engineering process directed towards using
existing (partial) solutions, we do not have insight in the reuse process
either.
We just do things without being able to explain why things work, should work,
go wrong, etc. The only explanations given are based on common sense
which is not enough from the scientific point of view.
%I will show how experience can be explained with which kind of theories.

\vspace{0.2in}
\noindent
{\bf Keywords:} science, methods, techniques, process

\vspace{0.2in}
\noindent
{\bf Workshop Goals:} Learning; networking; advance state of
theory of reusable position papers.

\vspace{0.2in}
\noindent
{\bf Working Groups:} reuse process models, reuse maturity models,
reuse education, reuse and OO, reuse and formal methods

\end{abstract}

\newpage

\section{Background (reused)}

In 1986 an Ada program library had to be build for the Delft Ada subset
Compiler. During this work we were thinking about facilities to offer to the
users. The step to reuse was made. Because of the Ada background we
concentrated
on components-based reuse on code level.

As reuse has two sides --- the form of the reusable components influences
how one can reuse and the process of reuse influences in which form one
wants the components -- a two-track research program was started in which the
ideal form of components and the ideal process had to be found and adapted
to each other.

\section{Position}

Since my first experience with software engineering and ever after I have
wondered why all methods only state the products which have to be delivered.
The syntax is described, the semantics get less attention, and how the
products have to be made, how to transform a requirements document to
a structure chart for example, is totally neglected.

When I started to develop my own software engineering method which
supports the reuse of existing artifacts and knowledge, I got a further
shock. The existing methods were based on experience only.
No sound theories backed them, no explanations were given why it should
be done in the way described or why it should work. No sound statistical
comparisons were made.

Software engineering research is not yet research in the scientific sense.
Software engineering methods are developed and tools are build based
on reasonable sounding arguments only.
Afterwards it is claimed ``it works because of the higher productivity'',
but we all know the Hawthorne effect. A change can have a positive effect
independent of the kind of change. Changing back to the old procedure
has again a positive result.
Therefore it is impossible to use this kind of information to build a unifying
theory on software engineering.
See \cite{bradley,habermann,richardson,thayer} for a discussion about
this topic.

Another reason is that if one tries a statistical sound way of measuring
the effect, there is the problem of the metrics. As Fenton \cite{fenton}
shows, we do not know what to measure, eg. should we measure lines of code
in a month for productivity or should we measure centimeters documentation.
We also do not know what we measure.
What does it say when we write so many lines of code?

As I got the feeling that software engineering is problem solving by humans
for humans, and that reuse is problem solving with existing (partial)
solutions,
I went to cognitive psychology to see whether theories existed
on how people solve and should solve problems to base my own method on.

It appeared that several kinds of problems existed, i.e. formal problems
and non-formal problems \cite{wickelgren79}, and that software engineering
could
be classified as solving formal problems. For formal problem solving
several theories existed.

Software engineering can be seen as a special form of problem solving.
The splitting of the software lice cycle into several steps is the division
of a problem into subproblems (a general problem solving method).
The use of program plans \cite{rist,littman,yu,wiedenbeck}
can be compared with the schemata \cite{mayer}.
Functional fixedness in programming was proved by \cite{mayer75}.

The human understander is best viewed as an opportunistic processor,
capable of exploiting both bottom up {\em and} top-down cues as they
become available \cite{letovsky}.
This is consistent with the memory model of the schema theory.
We see that software engineers do the same.
Generally, it is found that software engineers first play with the problem,
give partial solutions, go into details, etc. until they feel grip
on the problem (a mental problem model is created) \cite{guindon}.
From then on they first give a solution in general terms before they
specialize \cite{duncker}.

All these findings supported the idea that conclusions from cognitive
psychology
can be used in software engineering.

My work gives theories based on cognitive psychology,
and from the conclusions drawn a process is derived and necessary
characteristics for describing reusable components are derived.

My work has improved the state of the art by giving a process model which is
also refined to a method.

My work has improved the state of the practice as HP has used ideas from
it in their reuse project, the reuse process model as discussed in former
workshops has incorporated several ideas.

\subsection{Reuse}
Without knowledge of problem-related concepts, the memory quickly reaches its
limits when trying to understand code \cite{shneiderman}.
This is because the knowledge can not be related to existing schemata
and thus has to be stored as separate facts
in the short term memory. As the short term memory is non-associative
and can contain up till 7 items, one sees the relevance of laying
relations with existing knowledge
\cite{newell,wickelgren79,shneiderman,miller}.

There are different approaches when trying to understand code,
a systematic strategy and an ad hoc strategy \cite{littman,pinto}.
In the systematic approach first the total documentation is studied in a
systematic manner. In the ad hoc approach documentation is read at random.
The systematic approach can take
too much time for large pieces of program and the ad hoc strategy gives
poorer results when adapting a program.
Therefor documentation has to be in such a way that it is easy
to combine both strategies in an intelligent manner.
The documentation has also to be in such a way that
the limits of the memory are not reached very quickly.

In \cite{maiden} mental laziness is remarked as one of the problems with
reuse. In \cite{luchins} some experiments are done about how to prevent that
the habit masters the individual instead of the individual mastering
the habit. It appears that by promoting productive thinking the problem
of mental laziness could be overcome.
If a solution is actively verbalized transformation to new situations
becomes easier \cite{mayer}.
This improves reuse.
The active participation in finding a solution improves the recognition
of the possibility of applying the solution to other areas \cite{mayer}.

There are two basically different approaches to understanding a program.
The first is the systematic strategy, where the programmer traces data flow
and control flow throughout the program.
The second strategy is the as-needed strategy,
where the programmer reads only those part of the documentation or code
as (s)he thinks to be of interest \cite{pinto,littman}.

\section{Comparison with Other Work}
Maiden and Sutcliffe explain findings from experiments with help
of cognitive psychology. They also base tools on hypothesis from
cognitive psychology.

In Bill Curtis' \cite{curtis} collection of articles, one finds a lot of
articles which compare methods or techniques for parts of the life cycle.
But, as one of the comments from Curtis states, these comparisons are
mostly not sound on methodological level, no experienced programmers are
used thus the conclusions can not be extrapolated to experienced programmers
as it it known that experienced programmers work different than less
experienced programmers.

Fisher and his group have a model on how programmers work, based on cognitive
psychology, and base a series of tools on their model.

One sees that other persons and groups concentrate on the tool side of
software engineering. Where Mayer \cite{mayerCurtis} made clear that
   the syntactic sugar in which concepts are modeled is important
   for faster and better understanding of the used concepts.
   And it is not yet clear what kind of syntactic sugar is helpful and
   what kind is not. There are conflicting studies \cite{sheppardKruesiCurtis}.

\bibliography{dusink}

\section{Biography (reused)}

{\bf Liesbeth Dusink} is a lecturer at Delft University of Technology,
chair software engineering, since 1985. She teaches introduction in programming
in Modula-2 with VDM,
software engineering and object oriented approach,
and software engineering environments.
Since 1992 she also works as research engineer at Cap Gemini Innovation,
Rijswijk.
At Cap Gemini she designs in VDM and VDM++ and programs in Ada. At this moment
she works on a project for tracking and tracing of trains.
These two jobs together offer a unique combination of theory and practice.
\end{document}
