Customers angry, fighting unknown DLL dependencies

Question

I'm a one man show developing a C++ Windows application for a customer. Over the past several months we've been running to the same problems with missing DLL dependencies on customer machines. Despite my best efforts something keeps going wrong and we get angry emails back. My boss and my boss's boss are angry with me and the customers aren't happy.

I'm hoping you guys can help out and give suggestions/ideas on how to get the deliverables in order. Before some of the obvious:

1. I have no test machine. That is, I can't replicate the customer environment nor attempt to install the app on a "clean" system to catch gotchas before shipping.
2. I've tried using depends.exe to track down what versions of the DLLs my project is dependent upon. I'm shipping our code with the redistributables I've been able to find that way. After that it's an angry customer email waiting game.
3. I do have access to a 64-bit machine and 32-bit machine to install new builds. It always works there.
4. I'm required to use a third-party DLL which can not be registered (it's buggy as hell.)
5. I'm not supposed to use Install Shield, any other automated installer, or write an install script.
6. I provide written instructions on how to get the app installed (unzip, double click exe file.)

I'm tired of taking heat for this stuff. What am I missing that I could be doing? What should I ask in terms of support from my employer? How should I ask for that support in a way that they'll provide it?

Update:

Virtual Machine torpedoed. They don't want me spending all of my times setting up and tearing down customer configurations. Instead, I'm now working with the customer to get a base configuration so that I know the exact machine set-up I'm supposed to target. If it's not up to that spec, I no longer have to care. At least something went somewhere... although I'd still like a test machine.

Answer 1

You should quit. In your quit letter you should explain why the situation is ridiculous and sets both you and the customer up for frustration. Let's go over the things you've said about your situation:

I have no test machine. That is, I can't replicate the customer environment nor attempt to install the app on a "clean" system to catch gotchas before shipping.

No professional development firm releases products without testing install. We are a very small firm and we have numerous VM's that we run tests on and that we run our installers on.

I've tried using depends.exe to track down what versions of the DLLs my project is dependent upon. I'm shipping our code with the redistributables I've been able to find that way. After that it's an angry customer email waiting game.

I do have access to a 64-bit machine and 32-bit machine to install new builds. It always works there.

These aren't too bad or too strange. It is odd that you don't know what DLL's you're using but there's not much your employers could do for that unless you're maintaining an undocumented legacy system - then it's their fault for not documenting anything.

Unfortunately you've said these systems are not "clean" so it is very easy to lose track of what steps are actually necessary to successfully install the product.

I'm required to use a third-party DLL which can not be registered (it's buggy as hell.)

This happens.

I'm not supposed to use Install Shield, any other automated installer, or write an install script.

I provide written instructions on how to get the app installed (unzip, double click exe file.)

This is utterly insane. Customers are NOT capable of following basic instructions. The fact that you've been told not to use an installer to make the customer's life easier is almost certainly the cause of your problem. You can't tell what they've done. When you ask them they're going to lie or forget what they did...if they ever knew to begin with. Your employers have caused a sever support issue by this edict and the situation is just plain never going to improve for you.

Tie this with the first issue (not having adequate install test platforms) and your product is certain to fail. Your customers SHOULD be mad and you should be as well. The situation your employers have created is not one conducive to development of a successful product. There is, simply put, nothing you can do until these issues are addressed.