Trust No One
Have you ever heard (or asked) the question: “Why bother writing this…? Someone must have done this before!”.
The concept of taking a compiled piece of code and using it in different contexts was a great promise (and maybe it still is). However, it enfolds some problems with relying on a piece of code you can’t control.
I’m willing to bet every one had at least one bitter experience with some third-party library, component or framework. But let me humor myself with a simple (yet annoying) example. Imagine writing a server using a third-party framework, which supplies communication services as well as some logging mechanisms. You happily use this framework, since you don’t have to deal with all the gory (and boring) details. You don’t even have to worry about managing the log file. Perfect. Until, one day the server unexpectedly crashes. Before you know it, you start digging in your code to find what went wrong. After giving up the chance to find the bug in your code, you start to wonder: maybe the problem is not in my code? A few more hours in some newsgroups and you find the problem: It seems that the great framework you used has a limitation regarding the size of the message sent to logging. Not only is this limitation quite arbitrary, it is undocumented, and if the size of the message exceeds this limited size, some pointer starts to wander across your system’s memory. On second thought, writing a simple logging mechanism yourself doesn’t seem too bad, is it?
OK then. What is the moral of the story? Should we write every piece of functionality ourselves? Can’t we trust any one?
Naturally, most of us can’t write everything from scratch (nor do we want to). Coming to think of it, even the OS is a third-party piece of software we use all the time. We can’t be expected to write an in-house OS for our project. What we can do, however, is indeed trust no one!
Here are just few things that come into mind:
- Prefer components with accessible and understandable sources – Having the source code of the component is good for finding hidden, undocumented behavior. But this is true only if the code could be understood with reasonable effort. Otherwise, it might be easier to write it than to understand it.
- If you do have the sources, you might be tempted to change them. Unless you really understand every bit and byte in the source, this could be dangerous. You might never know all the effects an innocent change can cause to the component.
- Prefer a supported component - Free rides can cost you a lot in the future.
- Verify the functionality of the component - Test the component as if it was a component written in-house. You don’t have to test the entire functionality of the component. Just the parts you intend to use. It is bad enough to rely on a component you didn’t write. You shouldn’t be expected to also rely on the quality standards of the people who wrote it (especially if they are unknown to you).
- Isolate the component - Where possible, isolate the component from as much of your code as possible. This will let you ditch the third-party component in case it will fail to meet your expectations. This is not always possible (especially when using an extensive framework), but most of the time, we do not do it merely because we over-trust the component.
