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.