Why we should (not) develop on a server via RDP

Question

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.

Answer 1

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)

Answer 2

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:

PRO

• 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...

CON

• 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

Answer 3

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.

Answer 4

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).