Fang Talks

Do the impossible, see the invisible
02 03 17

Dependency hell

So this is the power of an enterprise-scale Microsoft stack.

Sometimes software depends on other software for part of its functionality. And that may have been a great choice. Why reinvent the wheel when you can just borrow a bunch from someone else, right? Things get a bit crazy though, when the software you depend on gets updated. Sure, you can just stick with the old version if it breaks your code in all kinds of ugly ways, but maybe some of the other dependencies you’ve accrued over your development lifecycle do require that newer version.

You can probably see where this is headed. Stretch the above out a bit longer, and you’ll get a nasty tangled mess of code that depends on other code which depends on some ancient artifact you need to place in a pentagram painted in blood. As long as it works, it works. But if something needs to change, and some of your dependencies fall over, you’re pretty boned.

I spent the last two days wrestling with a problem similar to this. We may be closing in on a solution, but it’s just all around nasty work. It’s not like we can just up and rewrite the mess into something cleaner though, the system is a tad too big for that. Not to mention I haven’t grasped all its details yet.

Working in software is weird.
~ Fang

Comments

  • 03/03/2017 (12:54 PM)

    This is why I don’t work in software. It’s bad enough seeing dependency hell from the outside. I recently had a program become utterly useless because it was dependent on something that changed. Luckily another program that did the same job still worked.

Post a comment

Your email will stay hidden, required field are marked with a *.

Experimental anti-spam. You only have to do this once. (Hint: it's "Fang")