\documentstyle[]{article}
\addtolength{\topmargin}{-1in}
\addtolength{\textheight}{1in}
\begin{document}
\noindent
David Golombek\\
6.033 Section 6, David Wetherall\\
Paper \#1: Problems of code reuse\\\\

In a perfect world, software reuse would be common practice.  In the
real world, the combination of the fallibility of human programmers,
the difficulty of writing side-effect free code, and the rapid
change of programming styles frequently make software reuse an
unreasonable goal.  Although managers might drool at the possible
increases in programmer productivity, and programmers might dream of
being freed from writing another linked-list class, rarely does the
actuality of code reuse live up to it's promises.

Safe, efficient reuse of a given piece of code depends upon the programmer
knowing exactly what it does and does not do.  There are two obvious
solutions to this problem.  The first is to provide very good set of
documentation explaining {\bf exactly} what the code does; the second
is too have the same coder use the code both times. Unfortunately,
most programmers are quite adverse to writing good documentation, as
seen with the Therac-X models, where documentation was written as an
afterthought, thrown in at the end, after the coding was complete.
The second solution questions whether this is code or programmer
reuse.  Ultimately, the question comes down to how the new programmer
can adapt to the existing code -- does he have to read it all to
verify and understand it, or can he look at a short description and
get going?

Even if the code being inherited is wonderfully documented, there is
still the matter of bug-for-bug inheritance.  While a piece of software
might work perfectly for years in one application, the change in
timing, environment, and hardware frequently brings out bugs when a
piece of code is reused.  These are frequently the most difficult bugs
to find, because they pop up exactly where least expected, the "solid
base" of old code.  As hundreds of companies currently attempt to port
their 16-bit Windows 3.1 code to 32 bit NT and Windows95 code, many of
them are finding their supposedly ANSI compatible, and therefore safe
code, was dependent upon the length of several system features, and
abruptly die when run on the new systems.  In these cases, it is often
simpler to rewrite the code entirely than to trace out all of the
dependencies.

As technology rises at it's breakneck pace, so do the methods and
techniques associated with it.  It is easily possible to spend so much
time developing a reusable block of code that by the time it is
complete, no one wants to use it anymore.  A company could easily
become so entangled in the two aforementioned problems that by the time
a library was usable, the next technology would already be standard.
Such is the unfortunate fate of many DOS graphics libraries -- years
spent in development, and suddenly Windows95 is the game platform to
aim for, with libraries pre-supplied by Microsoft.  

In a perfect world, code would be written correctly the first time,
and could be slipped into place in new projects without worry.  In our
real world, there are too many variables and uncertainties to worry
about to make code reuse a viable goal in most situations.  As always,
this is not a hard and fast rule, but for most projects, the gain is
not worth the efforts.  A clean start will make the project faster in
the long run.




\end{document}
