Every line of code is a liability

Over at DrunkenBlog there is a lengthy interview with Jonathan Rentzsch, Mac hacker of, among other things, mach_inject and mach_override fame. It's a more than interesting read, highly recommended.

Quote from the interview: "Because you have to write reams of code, your software develops premature rheumatism -- it becomes unnecessarily hard to make changes. Every line of code is a liability."

While this is certainly true, the question is how to deal with the problem this statement hints at: If every line of code you write yourself, and therefore have to maintain yourself, is indeed a liability, the route to go seems: "If you can use a third party piece of code (i.e., a library) for any job your application has to perform, you better use it!"

I don't necessarily agree.

Not invented here

Imagine, for example, you're writing an application in C or C++ that is supposed to be stricly UNIX based for now. Among other things, this application has to make use of System V shared memory. What do you do? Write a small shared memory wrapper class (assuming we're using C++) to encapsulate the various shm_* calls, accepting the liability? "No way!" you might think. "I'll make use of a well tested, proven third party shared memory library like libmm!"

Or maybe your application needs some sort of RPC functionality. "Not a problem", I hear you say. "We've got CORBA! Let's just use MICO and we're done with that!" And off you go. With a lot less code to write and worry about and a lot less liabilities for the future. Right?

Right. But not for long. Imagine your shiny application is a huge success and customers demand ports to Windows. And Mac OS X. Because you're a diligent programmer, you're absolutely positive your code will, with minor modifications, compile and work just fine under both of these OSes. So you fire up your Windows XP box, check out the source code of your app and begin to hunt for the necessary libraries.

Not ported there

You will soon find out that there's no such thing as a libmm for Windows. It just doesn't exist, and can't be ported without a major effort on your part. So what do you do? You get rid of libmm and roll your own, finally. Probably not without breaking some part of your application.

Or MICO. Yes, it's cross platform. Works on Windows, no problem. Also works on Mac OS X. It's just that it doesn't build with pthread support there, because the pthread implementation on Darwin is a little lacking in some respects. So, if your wildly successful application is indeed multithreaded (and it sure is, right?), you will find yourself in trouble again.

A million liabilities

Dependencies on third party libraries are a liability, too. Maybe even more so than code you have written yourself, because with your own code, there's a good chance you will be able to do something about it should problems ever arise. With a third party library that doesn't work on a new platform, every line of code in that library suddenly becomes your liability. And it could be millions of liabilities at once.

And even if portability isn't an issue, there's another problem: What if your third party library suddenly isn't being actively maintained anymore? What if it fails to build with that new version of gcc/g++ you want to (or have to) use? Many programmers have seen this happening when making the switch from gcc 2.95 to 3.x, for example.

Think before you borrow

Sure, every line of code you write is indeed a liability. But adding dependencies on third party libraries to your application is not without its pitfalls, either. So what do you do? Here are a few hints:

As a basic rule: Avoid pulling in dependencies in your application wherever you can.
If you need a certain piece of functionality, look for a library that does exactly what you need, and nothing more.
Found a library that does what you need and a thousand other things? Maybe you can get away with extracting the one tiny feature you require from the source code and integrating it in your application. Of course: Check if the license permits for this!
Even if you might not need the library you are about to pick on a different platform now, if your application is successful, you will need it some time in the future. So if it's only available and tested for, say, Linux, think again!
Check out the major cross-platform-frameworks like APR or the Netscape Portable Runtime. These are both huge and you might not need even half of the features they offer, but they're certainly being supported very well and there's more than a good chance this will stay that way.

Maybe it all boils down to: Think before you code. And also think before you borrow.

<< The Black Art of Optimising

Software Development