#softwarereuse

Several weeks ago, a fellow I went to school with was decrying bad spaghetti code, sending out a call to trash the entire project and start over.  I reminded him the age-old aphorism that the majority of software cost is spent on maintenance, which after not finding in me a shoulder to cry on, he irritably disregarded.

As engineers we dream of building something fantastic: a tower, a tribute to the heavens that will be elegant in form and function, something our peers can marvel at.  But as powerful as our favorite language's paradigm is, it's nothing but vain ego-stroking unless it gets the job done.  I'm not devaluing clean, fresh code.  On the contrary, every time we add another inspector to a class, for the sake of maintainability the ramifications need to be thought through.  But the truth is most every kind of module you need already exists, and much of it is in a licensing model compatible with what you're working on.  The best code you can write is the code that you don't.

Fact being money-wise you're going to spend most of your resources maintaining something written long before, so the least you can do is muster a positive attitude and see it as a chance to bring more value with less effort.  Reading, understanding, and utilizing other developers' source (which by the way is pretty much the same as anything you've written and moved on from more than six months ago):  these are some of the most important skills you can refine as a software engineer.  Knowing what the code was originally intended for, and understanding the thought behind its creation will pay off many times over.  Fail to heed this and along the way you'll find yourself rewriting a lot of modifications.  The other side of the coin is unless you're working on a throwaway prototype for a personal project, it pays to spend some time documenting your code and make it easier for other developers to reuse down the line.

Recently I started work porting a Carbon-based frontend of the popular game console emulation library GME to my native 64-bit OS X Lion.  In about eighty hours of work I got from a zip file of code that didn't compile to an app rewritten in Cocoa and Core Audio that replicated the core functionality.  I did this in less than 500 lines of code switching out only the GUI, application timing, and audio interface, while maintaining the essential application flow.  This was possible because the source was clear, consistent, and the key points were well documented.  I didn't agree with a lot of the mechanisms and models used, but I understood the motivation behind their selection and respected the unity of the entire package.

The key challenge for my project moving forward will not be restoring the stubbed-out functionality or modernizing the UI, it'll be preserving the code that works intact, and clearly demarcating my modifications and extensions.  Because in another ten years when I've long since stopped working on the project and some other developer wants to cut their teeth on programming for the latest platform's APIs, I owe them the same professionalism the original developer showed me.