Explain DLL Dependencies to a lay person

Question

This follows from a previous posting I made about lack of a clean test machine for software installations. I'm doing a bad job of explaining how DLL dependencies work and how some machines might not have the right libraries at the time of installation. The problem is that it's being viewed as a defect with the build process. I'm trying to educate the higher ups that it's not the build process per se but rather the installation process which is to blame.

Here's a quote from my boss relating subcontractor work to our work to put it into perspective:

I'm not a software person. All I see is that when they hand something to us it just works but when we hand something to the client there's all sorts of problems. There must be something wrong with how you're building the code.

[edit]When the subcontractor applications arrive, they can be copied right onto our development machines because our machines contain all the right Microsoft runtime libraries. However, on the customer machines, not all of them contain these dependencies.[/edit] It's very easy to see how someone who is smart (scarily smart) could come to the wrong conclusion. So how would you explain the whole DLL dependency issue?

Answer 1

you could use an analogy that might be more familiar to him. Something like moving into a new office.

Lets say you are a contractor and you decide you are going to move into a new office. you make a list of all the things you think you'll need in your new office, internet, phone, fax, photocopier, stress ball etc. You then decide to move into a shared office, which already has a lot of this stuff, and more besides. So you move in. you take with you the stuff that it doesn't already have, like stress ball, bonsai tree etc.

what you don't realise is that as well as all the things on your list there are some other things that you start using at the shared office, like the coffee machine, hole punch etc. you do this rather mindlessly so you don't add the things to your list of 'necessities'.

then you fall out with some of the guys in the shared office so you decide, what the hell, you'll go it alone, and get a brand new, empty office. So you get out your list of everything you need and ring round and start ordering it. Great. Except that when you move in to the new fresh office, you realise there is no coffee machine, hole punch etc.

So whilst you are still as able as you were before, you can't do your job fully as some of the dependencies you need are not available.

So in this 'you' are the software you have written, the office is the machine you are installing on, the dependencies are the things on which your software depends, and the list of what you need it the installation build process.

Maybe...

Answer 2

He is right that you're doing something wrong, because if they're not standard system DLLs, you should be packaging those DLLs with the program, possibly using an installer to get the necessary prerequisites on the system. If you aren't allowed to do that, then you need to do things differently, like using static linking (where the necessary code is included into the executable).

Nevertheless, here's an analogy which you can use to explain what the problem is.

A program is essentially a worker who knows how to do one specific task (it can be a very complex task with lots of subtasks or a very simple task, but it's stil just one task in the end). In order to do those tasks, he has to use some set of tools - the DLLs.

Different tasks call for different tools - just like you need a saw, not a hammer, if you want to cut a plank in half, you need different DLLs to do different tasks.

If the right tools (DLLs) aren't available, then the worker (program) can't do his job, because his task depends on those tools. If he can't do his job, he'll tell you "I don't have this tool, and I need it to do what I'm supposed to do."

That's what's happening to your customers: you've given them the worker (program), but you haven't given them the tools (DLLs) and the worker didn't bring them (linking statically).