Skip to main content

Ask Steve! - How to develop code to avoid dependency problems

Posted by s.crouch on 27 May 2011 - 3:57pm

This post is inspired by a forum question from one of the SeIUCCR Community Champions, regarding software versioning issues on NGS clusters…

Developing code that depends on other code is  common – we do it all the time, even with the simplest program. Software reuse is good practice, but a problem can occur when you take your software from its well-known and tested environment, such as the one within your research group, to a new environment. You can find that the dependent software (the software you reused) isn’t available on the platform, or a specific version of that software isn’t available. If you’re unlucky, this dependency failure isn’t discovered until an infrequently used (and ill-tested) code path is executed sometime after deployment.

The good news is that a little bit of thought and preparation early in development can avoid a world of hurt later. It’s like not preparing a parachute properly: if you’re lucky it’ll deploy, but if you’re unlucky you’re going to be very disappointed. (And in both cases, you’ll be left with a nasty mess to clean up.)

Sometimes you can include the dependent software within your own deployment (e.g. Java JAR files, sometimes even Perl libraries), but very often this is neither a good idea nor possible for technical or licensing reasons. This is especially the case when working with entire software packages hooked together at a higher level. Packaging the dependent software can leave you with more to maintain, more internally complex software, and issues and conflicts if the packaging is not done correctly.

The answer to dependency problems is to ask lots of questions. and remove false assumptions about where your software will be used and any dependent software it uses.

One trick is learn about the target environment for your software: operating systems, environments, deployed software, and suchlike. Does your software need to work  across platforms? If the environment is a production grid infrastructure, what are the constraints for deploying dependent software or packages? The key is to know what the end-user community or system administrators are expecting from your software – and the best way to find out is to ask them.

You can also ask a few questions of the dependent software you are using: has your community converged on using a particular package? Does it have all the features you (will) need? Does it have a sustainable future, support, frequent releases?

For a possible candidate version of your chosen software, you will need to ask whether there are any known issues, bugs or plans that could cause problems. Will any soon-to-be deprecated features affect your software? Also, consider if a planned future environment upgrade will cause compatibility problems.

Finally, develop your code defensibly and take a changing software environment into account. Don’t use deprecated interfaces, try to keep the development and deployment environments as similar as possible, test often and well, loosely couple your code and always adopt good software maintenance practices (because you can’t go wrong with that one!).

Remember: assumptions can kill (your software)!

‘Till next time!

Links:

Share this page

We use cookies on our website to support technical features that enhance your user experience.

We also use analytics & advertising services. To opt-out click for more information.