Paul W. Homer on his blog, The Programmer’s Paradox, posted an article about dependencies in software solutions. I constantly fight with this issues: old code vs new code, introducing a dependency or writing your own. I wanted to comment on his blog but I just couldn’t summarize everything I wanted to say in one comment. So here are some of my experiences with the dependency issue.

It’s interesting how you always think something is a good idea until it turns against you. So, if you don’t want to write the code somebody already has written, you’ll find out that this code is slow/ugly/buggy/heavy. If you, on the other hand, are smart and write your own code, you may find too late that it will took too much resources and it’s not as simple as you though it is and some functionality you just can’t implement on time.

Maybe the worst code is the in-house code that works good but is based on old presumptions about hardware, requirements or interoperability. I find such code hardest to evaluate. It’s a burden if it’s model is not extensible enough but you must stick to it because any replacement requires big investments.

In any case, you depend on something you can’t easily fix if something goes wrong so you have to be very careful when introducing new dependencies in your software. Of course, you always depend on something, like operating system, database and framework. But every time you add more to this dependency stack, you exponentially increase the risk for something to go wrong.

Story about third party component

I had to maintain and extend a document management solution in which images could be attached to a document. User could view an image inside the application and do some simple manipulation on it like rotating, scaling and moving. A typical scenario where you entrust specific set of problems to a third party library.

I raised some question about size of this component. Also, it was pretty memory heavy and was leaking in some cases but nothing was serious enough to think about replacing it. The only problem I saw about this component was abstract to others: we were using it for image viewing but the component was designed for image editing: conversions, effects, filters and annotations. Displaying the image was only smart part of it’s functionality. Sometime ago, we allowed the users to edit this document but nobody was using this feature. And why should they? If someone wanted to edit an image, he’ll use the right tool for the job, not document management software.

As the component was part of our library for some time, team started to use it in more and more cases: generating thumbnails on the server, drawing reports or generating images from metadata. We had deep dependency then, disaster waiting to happen.

Of course, problems came immediately. First, we wanted to make a lite version. We did it but imaging component took a third of the installation size. Then Microsoft made SP2 for XP and included a firewall. For some reason, component failed to load on one of three machines providing us only with some general error. We never discovered what was wrong but after some patches from Microsoft error was gone. Sometimes, the component didn’t work if PC wasn’t connected to Internet.

When two of our most important clients decided to upgrade our application, component finally gave us a good reason to kick it out of our software. Upgrades were succesful, but new installations didn’t work at all. Application hung at startup without an error. We couldn’t reproduce the error at home so we spent some time to organize debugging at customers place, something I don’t want to repeat again.

It turned out that imaging component failed to initialize. But instead of throwing an error, it just hung up and we couldn’t do much about it. We striped the component out and temporarily used version that opened images in an external application. It did the trick but the incident hurt our reputation.

Now we have our own component for image display, nothing fancy, just zoom and rotate. When our own component is not enough, we have a plug-in for image manipulation based on FreeImage. But important is, we don’t have deep dependency anymore.

Comments RSS - leave a response - trackback