Application Fugue

So I recently decommissioned one of the PCs here in the lab. As part of it, I went through the Adobe process to decertify Dreamweaver on one machine, uninstall it, reinstall it on the new machine, and recertificate it. Then I created a shortcut of it on the desktop, and I ran it:

Dreamweaver wanders around

Oops.

Well, I wasn’t going to spend an hour or so on the phone trying to fix it, so I uninstalled it and reinstalled it on the new machine, and when I tried to run it again, I got the same catastrophic error message.

Was it time to call customer support and face a bullet of whatever precious metal Adobe uses? Of course not! I’ll take another look and….

Instead of creating a shortcut on the desktop, I’d copied the executable there and tried to run it, and the poor little application was lost in the big forest without its dependencies.

Yeah, there I was, a computer professional making a mistake that rendered Adobe Dreamweaver speechless.

Dreamweaver is shocked!

So, what does your application do when it cannot find its dependencies? If it’s anything like this particular application, it spits up an unrelated error message and it asks you to call support. And support will have a werewolf of a time trying to figure it out.

So play around with your executable locations, including putting dependencies on network drives and not connecting to them, altering paths, maybe renaming directories without changing them–particularly if you can change the name of a directory from within the application and the application stores the hard file path somewhere within it (I used a testing tool once that let me do that, and then it could not find its own tests).

Granted, you’re not going to convince many people that these are high priority defects, but it’s something you should still consider when trying to build a quality application.

Comments are closed.


wordpress visitors