Code Assets
Volume Number: 10
Issue Number: 2
Column Tag: Inside Information
Source Code Assets 
Rewrite vs. Reuse
By Chris Espinosa, Apple Computer, Inc., MacTech Magazine Regular
Contributing Author
A couple of issues ago I wrote about code reuse, and how developers who create
multiple related products can save time and money by investing a little up front in
good, reusable code. I stand by that idea, but a friend of mine in the development
community has proposed a pretty audacious alternative.
Reusable design is great, he says, but the source code itself is expendable. You
should plan to depreciate and replace your source code just like any other asset of your
company, like office equipment.
For those of us who’ve grown up in the software business, this is a pretty radical
idea, because of our attitude towards the preciousness of source code. Source code is the
family jewels, it’s the secret recipe to how your application delivers its unique
functionality. You keep it locked up; you don’t print listings in the manual; you make
sure your competitors can’t get their hands on it. Otherwise, the logic goes, somebody
will take your hard work and steal it. They’ll be able to deliver the benefits of your
design and your algorigthms without the labor of inventing them, and not only take
some of your market share and revenues, but profit more from it too.
This is reasonable, but it’s created a protectionist attitude towards source code.
Obviously, anything that is of such value to your competitors must be of value to you,
too. I remember a very old Peanuts comic strip where Lucy stands on one side of a
closed door eating candy while Linus suffers on the other side of the door. She calls the
candy “Spite Candy,” and admits that “the problem with Spite Candy is that it never
tastes very good.”
The problem with holding on to the source code that’s the secret to your success
is that it can hold you back. If you give them enough time, your competitors won’t need
to abscond with your source; they will have written their own that’s designed better
and implemented better, and they’ll take your customers rightfully.
This doesn’t mean you should rewrite your application from scratch every
release. Of course you can’t; it’s too much work. And everybody knows that rewriting
code can introduce bugs that take time to fix, or can disturb the backwards
compatibility of the application. Nobody wants to explain that a feature in the last
release works differently now because you “fixed” it.
But still, if your program has been on the market for a few years and there are
other, newer competitors in your category, you have to do something other than just
adding features and keeping up with the OS and hardware advances. Otherwise the
“legacy” code in your application will weigh down the whole structure and decrease
your ability to stay competitive.
The trick is to change your attitude about the source code. Treat it like your
grandfather’s axe (as in the old saw: I still have the axe my grandfather used, though
I’ve replaced the handle three times and the head once.) Institute a program of periodic
refurbishing of the source, module by module, with the aim of having 100% turnover
over a period of a few years. But do it a little at a time, so that the inevitable bugs you
introduce can be isolated and fixed.
Focus on modernizing the code and improving the efficiency of each module. In
doing this you may discover that some modules are the code equivalent of the appendix
or tonsils: once useful, now annoying. You may see old code in a new light, and be able
to swipe code from one product for use in another. And eventually you may get inspired
on how to design a second-generation application, with an architecture that adds years
of life to the application.
You have a unique and valuable asset in your source code. But you should do more
with it than keep it locked up except when you’re sending it through the compiler for
another minor rev. Though opening up long-closed source files is annoying and risky,
you need to air it out every once in a while. Stop taking your assets for granted.
Understand that if you leave it alone, it depreciates just like any other material object
you own; but if you constantly refurbish and replace its source code, you can add years
of marketable life to your application.