I have a client who is requesting that we develop their fairly small web application directly in their environment by RDP to the server that will host the app. They have had a contractor do this for a while and it has worked "fine" for them, so they are comfortable with that approach. The client's biggest concern at this point is cutting costs - they have a very tight budget.

My manager does not seem to care or think that it makes a difference. However, I strongly do not agree with that practice.

How best can I convince the client that it is bad practice to do things that way? I need to use "management" language, not developer language.

I can think of a few advantages of developing locally (as a developer):

  1. We can not guarantee code quality in the remote environment (why not?)
  2. Internal team collaboration increases efficiency (how?)
  3. Internally, we can take better advantage of source control (although that can also be installed on the server)
  4. Internally, we can follow better quality control processes
  5. With RDP, only one developer can work on project at a time
  6. Developing locally increases a developer's efficiency (how? maybe because it is their comfort zone? maybe with multiple monitors? how does that benefit the client?)

Unfortunately, these do not necessarily translate to something management appreciates (e.g. dollars and cents)

Please help.

  • I would like to hear the reasons the client gives you to support the RDP developing thing. You mention budget but you need already have a local machine. – Tulains Córdova Apr 11 '14 at 21:18
  • Only your #5 and #6 are supportable. #5 should be obvious - one RDP session, one programmer. #6 should be demonstrable - either RDP will be slow and painful, or it won't. – Ross Patterson Apr 11 '14 at 21:28
  • 2
    Odds are, the client thinks that by using RDP the code will be "safer" since it will only exist on their servers. Years ago, my current employer had all offshore developers log into a shared network server in order to develop our application. We finally got each offshore developer their own VM, which allowed them to "develop locally", without letting the code leave our network. – Adrian J. Moreno Apr 11 '14 at 21:31
  • 1
    the client wants to monitor what work is being done at any given moment. Working directly on the server gives the client direct access to what the developer is doing at that given moment. The pattern "I'll do work and update the server later" isn't acceptable for the client. There are ways to setup a staging server that pulls the latest changes, but your problems are more with the client then how you're going to do the work. – Reactgular Apr 11 '14 at 21:32
  • 2
    7. - you are at the mercy of your internet connection. With a local environment, even if the internet connection goes down you can still work. – GrandmasterB Apr 12 '14 at 3:55

You're trying to use a bulldozer to hoe a garden. Stop it.

The client & your management are happy with the current (primitive, simple, dangerous) process.

This process works for a small app with a single trusted developer.

Since you're making all your changes on production, if you introduce a bug it's likely that someone will spot it quickly. Not all businesses consider a bug to be catastrophic - they just expect you to fix it. They also get instant feedback on the work you're doing.

This sort of customer is relatively unsophisticated and may not appreciate the value that testing, source control, team collaboration, QA, backups etc can bring.

Until the customer's ready to advance, any attempt to bring in "all that overhead" will be met with resistance.

(From a technical point of view you are of course absolutely correct. From a business point of view, all that mumbo-jumbo techie stuff sounds complicated and doesn't visibly add to the bottom line)

  • But, but, but... if a bug is found, and the contractor also touches the server/app how do we know that the bug was there when we built the app. :( – Alfero Chingono Apr 11 '14 at 22:27
  • 2
    You don't. From the customer's point of view it doesn't matter - the bug needs to be fixed & you'll be fixing it no matter who put it there. – Dan Pichelman Apr 11 '14 at 23:13
  • I don't like your answer, but it seems to be the correct answer (judging by the votes)? Don't get me wrong, you make very valid points, but I was looking for support... not voice of reason :) – Alfero Chingono Apr 14 '14 at 19:45
  • 1
    "but I was looking for support... not voice of reason" This sounds like something you could read in a Dilbert strip... "Stop making sense!" :) – toniedzwiedz Apr 14 '14 at 19:51

You've come up with the answer you want and now you're just soliciting confirmation. STOP IT.

The correct question isn't "Why shouldn't we...." -- rather it's "Should we...." Research the underlying question, don't just try to support the answer you want.

Here's some starters:


  • Lower cost (multiple thin clients)
  • Higher flexibility (any machine will do as long as it supports RDP)
  • Single predictable environment for building and development
  • Greater control over the code; it all stays in one place
  • Code can't "get lost" on someone's laptop somewhere; management always knows where the latest version is
  • Easy to transfer ownership of the project between programmers; just give them the new VM
  • and much more. I'm not event trying...


  • Only one copy = single point of failure
  • Greater opportunity for trade-secret exfiltration by a malicious developer
  • Requires an always-on Internet connection
  • Development environment is maddening over a high-latency link
  • RDP sometimes "gets in the way" -- keystrokes get interpreted by the host OS, for example
  • Sales people must love working with you ;) – JeffO Apr 14 '14 at 13:19
  • I am not sure that "only one copy" is necessarily a real limitation even if development is primarily done on only one server. There is nothing to say that setting up a secure Git or Subversion repository that is externally accessible from the web isn't a possibility. The OP could setup an external source control repository in his own network that can be reached from the development machine. There is now source control and more than one copy. – maple_shaft Apr 14 '14 at 13:46

Ah, the client with a small website who doesn't want to pay too much.

You can't argue your way is better when the client has evidence that the other developer was able to make it work. Let the client know that your group is not use to working that way and if you have to drastically alter the way you work, you cannot predict how effective you'll be. From a financial perspective, the client shouldn't want to pay you to experiment and learn on his time. Maybe it will work, but he cannot take that risk. You don't want to make promises you can't keep.

From a business and a technical perspective this is a bad client. The development environment restrictions are a feature the client doesn't want to really pay for.


An RDP connection is going to be slower to work on due to the latency. You'll type a line of code, and have to wait a bit for it to show up. On a fast connection (LAN) this probably won't be noticeable, but on a slow connection (like over an ADSL link) this will be noticeable, and (in my experience):

  1. Make you work much slower (as you wait for the keyboard and the mouse pointer to catch up). If you're billing by the hour this might be something that your client will have an issue with.
  2. Drive you slowly insane (after an hour of working over RDP I gave up and just drove to the other office).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.