Justin James discusses several things that you need to evaluate in a third-party dependency before you decide to use it. Then, he recommends what developers can do about it.
I wear many "hats" in my job role. One of my "hats" is to run the company's servers and networking infrastructure, including deployments of enterprise software. This puts me on the front lines when it comes to dealing with applications that may be great tools but are huge headaches.
I have come to realize that when developers rely upon third-party tools or systems to make their applications work, they are putting the customer's perception of the quality of their product into someone else's hands. And unfortunately, many of these third-party components are the cause for the customer to go insane. While some customers might differentiate between which product caused the problem, they will still blame you for choosing a pain-in-the-neck system as a dependency.
Here are several things that you need to evaluate in a third-party dependency before you decide to use it. (There are many more ways in which a third-party component can make your customers hate you — these are just the biggest ones.)
Some dependencies cannot be installed as part of your installer, and the customer is forced to install them separately; this means that this system had better be easy to install! Yes, you can always tell the customer to "read the directions" and hope they leave you alone, but the fact is, customers hate that answer.
System administrators are busy people. With all of the budget cuts and such, most of them are overwhelmed just keeping existing systems running. The last thing they need is to spend time and energy trying to install your application or a sub-component of it. And do you know what happens if the customer has a hard time deploying it during a trial or a pilot program? They don't buy it if they can help it. And the memories last for a long time, too. I remember being involved in a purchasing decision for a major (as in, $100,000) piece of software. One product wasn't even evaluated because the systems administrators had used the previous version and hated the installer, partially due to third-party components. Not many companies can afford to lose a sale like that over an installer.
Every once in a while, you'll see one of these dependencies completely violate security best practices; when this happens, you can be sure that your potential customers will be severely turned off by your application.
For example, if your dependency requires that a server be connected directly to the Internet, you can be sure that the customer's IT team will do everything they can to keep your software off of their networks. Likewise, if it must be installed in the LAN but needs to be accessed from the Internet, that's a big problem too.
There are all sorts of ways that these third-party components can trample security policies, so you need to be on the lookout for them.
One application I deal with frequently has a third-party licensing component. On a regular basis, my users would tell me that the software is no longer licensed, which caused me to open a ticket to get a new license file. The turnaround time would be about 24 hours, leaving my users dead in the water. Needless to say, people were getting very grumpy about this, and the application became a very expensive inside joke (the per-seat license cost could buy a small private island).
The worst offender I've encountered is SQL Server Reporting Services (SSRS). It's absolutely miserable. Every time I install patches for Microsoft CRM, SSRS seems to break, and the "solution" is to uninstall/reinstall the SSRS connector on my SQL Server. This is an absolutely unacceptable situation. SSRS is also the root of nearly every hassle I have ever had with Team Foundation Server. I've made a promise to myself to fight, tooth and nail, against working with any applications that rely on SSRS, because as a systems administrator, it is not worth it to me.
What can you do about it?
First, I recommend that you manage your own development environment (or set up a virtual test lab) and try to run your own application with all of the required items yourself. If you can't handle it, and you are not a professional systems administrator, there is a good chance that your customers' sys admins will hate it too.
Next, you will want to have a few sys admins that you know, trust, and respect take a look at it themselves. Perhaps you can have your own in-house IT staff evaluate it; ask them to treat it like it came from a vendor, and ask for their honest opinions. Don't be defensive if they say it is horrible — remember, you didn't write it. Try to get their feedback as early in the development cycle as possible to avoid being locked-in to using it. Do some research on the Internet, and see what other people are saying about these dependencies.
Finally, make sure that your beta testers are asked not just about your product, but the overall experience as well.
J.JaDisclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
———————————————————————————————————————————-Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!