In addition to writing code from the ground up, we also work with other library developers and we package the libraries in a C# or Java API which is typically easier to work with or more convenient for our customers. Many of our customers aren’t comfortable working with C++ libraries or sometimes the C++ libraries have awkward interfacing and that’s fine. We’re very good at taking this type of API and presenting it in a way that feels right for .NET or the JVM and integrates with the rest of our code base.
Still, the same way that you work with us, we have to, at times, work with other library writers and we find bugs every now and again.
Here are five tips for working with library creators to get the most out of your interactions.
- Make sure that you are using the library correctly. The reason is that (hopefully) your library has a model of operation that lends itself to a particular model of usage. For example, some libraries might have an opaque object with events that you hook into and you make a method call which will induce the events to fire (and for you to get your data). Others might have a model where you set elements in a property bag and make a call to get data in the format you request. If you’re using a library in a way that goes against its model, you might induce worst-case performance. I call this an API impedance mismatch. In this case, go back over the documentation and sample code and see if you’re following the model. You might, in turn, have to refactor your code to handle the impedance mismatch.
- If you’re getting a hard crash (either a NullReferenceException at the .NET level or the C++ equivalent of dereferencing a null or invalid pointer), your work has just begun. You need to ensure that all the input parameters you’re sending to the library are valid. This is especially frustrating for code that uses a property bag interface, but you really need to do this. You may find out that you’re just forgetting an argument or neglecting to set an input parameter correctly.
- If you think you have an issue, try to reduce it to a simple example. This isn’t always easy or quick, but in the long run it is a huge aid to getting a defect fixed sooner rather than later. For example, we have had customers who have supplied code that we could integrate right into unit tests. Suppose that you’ve got a very complicated project that doesn’t lend itself to being isolated. What do you do? I’ve written adapter classes onto an existing API such that by turning on a flag, I could log all calls into and return values from an API and in the log I wrote out source code that I could pull from the log and put into its own isolated project. You’d think that this is time consuming and to a certain extent it is, but if you think about the difference between ‘a few days of work’ and ‘never’, then the choice should be easy. If you can’t do this, offer to do a remote session of some kind to show what you’re seeing.
- If you have source code and your usage license allows it, step into the code by all means and see if you can track down the bug. Not your job? Yeah, but I figure that if I can track down the issue myself, it will get fixed faster. Not only that, it might also break down any incorrect assumptions I’m making about the library itself (see tip one). What if you don’t have the source? Well, perhaps your license doesn’t forbid disassembly of the library. If so, there is a disassembly window in Visual Studio that you can use. Not everyone knows assembly language and I save this for situations when I’m completely dead in the water, but if are decent enough at looking at assembly and intuiting the high-level code it came from, this can help too.
- Remember that your library providers are human. You make mistakes. They make mistakes too. By keeping your discourse civil, you’ll be treated well in return.
About the AuthorFollow on Twitter More Content by Steve Hawley