Menu Close

Dealing with Defensive Developers

In the past couple of months I’ve had a couple of clients come to me where there were issues with other software developers they use. “Issues” is putting it mildly.  These developers were making it difficult, if not impossible, for their client to work on their own projects.

It’s a bit of a pet peeve of mine when other developers are uncooperative or seem like they are holding their clients hostage in some way.  Developers should be putting the needs of their clients first, either by providing a service or delivering a product or enhancement.  If that means cooperating with another developer who specializes in a particular technology at the client’s request, then they should work together instead of fighting and making things difficult.

The Importance of a Written Agreement

In the first case I encountered, a client of mine had hired a previous developer through a bidding site to help build an integration between a piece of software the client had decided to use and a third party service.  This would have been fine, but the client made a big mistake.

They didn’t have a written agreement with the developer.  This makes things tricky in a couple of ways, the most important being the definition of ownership of the work.  The end product was hosted on a server of the developer’s, supposedly in order to save the client money.  However, the client has no access to this server and the work provided.

There is no definition as to whether the work done is owned by the developer and is being provided as a service, or if the coding is owned by or licensed to the client.  Some people would argue that since the client paid for the work, they own it and should have access to it.  However, the client has never had the work in their possession, there was no work for hire agreement in place, and no specific license is assigned formally. In the U.S. at least, paying for work doesn’t automatically transfer copyrights.  My advice is to always have a written agreement with your developer, setting out at least a few specific things.

Payment, ownership/licensing of the final product, and the services provided should all be included.  I am not a legal expert, so I advise anyone wanting to look more into this to check out books on and have a lawyer you can consult with about specific contract questions.

The result of this is that the client’s primary source of income is controlled by an integration residing on the server of the developer that the client has no access to and the client is afraid of replacing the developer because of this.  In addition the client has stated that the developer has tweaked things without the client’s consent in areas to which he had no experience.  This is why setting down the services in the terms of an agreement is important.  A contract developer should not be making changes without the consent of the client.

Unfortunately there is no easy way out of this situation beyond having another developer re-write most, if not all, of the custom code unless the client can convince the developer to put the code on a server of the client’s and clarify their licensing terms in writing.

Advertisement: Your content continues below.

Working With Controlling Developers

Another situation I’ve come across is a problem with access.  A client has a web developer for their website/shopping cart.  The client approached me about a job because I have special knowledge in a tool they are using and I have an integration developed between that tool and the cart.  In order to make an assessment of the work involved, I needed to have a full picture of the systems in place.  So I asked for access to a copy of their site with all of their customizations so I could see if there was any extra modifications I had to take into account.

Now, on a side note, I believe everyone with a shopping cart should have a development copy, that doesn’t have live data, for devs to work on and test modifications on.  This also protects live data such as credit card numbers (which shouldn’t be stored anyway). Having a bottleneck for who can access the live site is perfectly fine.  In most cases I don’t want access to a client’s live site unless they don’t have anyone else who can make necessary modifications (I prefer making it as easy as possible for the client to make the mods themselves by handing them a zip file and instructions or a simple script to run).

Back to the issue of access, in this case the client did not have a dev copy of their site and their web developer declined to give me access to their live site.  I, thinking this somewhat reasonable, then asked for read-only access to the site, thinking they were just afraid of me changing something I shouldn’t.  After all, I just wanted to look and assess, so read-only would be sufficient.  This request was also declined.

At this point I started getting a little frustrated, which is unusual for me.  I had to tell the client that my assessment would be limited and I couldn’t guarantee that no problems would arise.  Their web developer would have to deal with those.  I could only surmise that the web developer was being uncooperative because they were afraid they might lose work to me.  This is silly as I was brought in for one specific project with a pretty narrow scope.  Of course the other dev doesn’t know me, but if a client decides to work with me over someone else, that is entirely their decision.  I simply do the best job I can.  While I want to make money too, my main concern is keeping the client happy and helping them be more efficient.

This unfortunately is a situation that a merchant must take control of though.  If you want another developer to have some access to your system to do an assessment, the person in charge of that should not prevent it.  They can certainly express concerns to be addressed, but outright refusal should not be acceptable.

My frustrations have prompted me to write this article for a couple of reasons:

  • First, merchants should be aware of dependencies on developers and have a plan before working with one.
  • Second, these situations are stressful for you as merchants and any other developer who has to work in these situations, and I wanted to help you think about them and avoid them if possible.

Have you had any bad experiences with developers?  How have you dealt with them?

Leave a Reply

Your email address will not be published.