Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Sorry for the confusing title. Let me explain:

I am currently trying to get a site developed. My current developer has taken the site about as far as I think they are capable of and I am planning on hiring another developer to put the finishing touches on it, debug it and upgrade some of the more technical details.

The site is hosted on my current developer's server. They are scheduled to work on it until mid-April, at which point they will transfer the site to my server.

I would like the new developer to get started on the upgrades to the site as soon as possible. So my question is this: Is it possible for the new developer to start working on upgrades to the site while it is still on the old developer's server (and without the old developer knowing about it)? Would the new developer have to create a mirror site and work on it that way?

I'm having trouble imagining if this is possible so any advice you can offer would be much appreciated!

share|improve this question
    
"My current developer" and "the new developer" are two persons at the same company or two different companies? –  user1249 Mar 20 '11 at 11:49
    
Two different companies –  user20688 Mar 20 '11 at 12:56
1  
Technically possible, but you are now in contract land. –  user1249 Mar 20 '11 at 13:48

3 Answers 3

(and without the old developer knowing about it)?

Wait, you want the new developer to start working on the site without the old developer knowing? Thats really not going to work.

The new developer could just take a copy and start working on it. But they will start to have two separate code bases and merging them together at the end will be a overhead, how significant its difficult to say.

They can't work on the same server without the old developer granting access, or maybe you give the new developer your account quietly. Either way, the old developer will start noticing when new code starts to appear or worse case, they will start to work on the same thing and because they don't know about each other they will create massive conflicts in the code.

2 developers working on the same server is never a good idea anyway. If something breaks, you don't know which bit of code/developer to start looking at ...

The only way this would go well is if the old developer agreed on working patterns with the new developer. They don't have to work together on the same thing but they do need to organise (eg. "You finish that bit and I'll look at this separate bit and we wont get in each others way")

If your worried the the old developer will go off in a huff or refuse to co-operate, then you have bigger problems than just dealing with technical access issues.

share|improve this answer

Usually you use a SCM (SVN, Git, etc) and a local fake environment for development and testing, in which case a new developer could simply check-out the current source and start hacking on it, provided he gets an account there - or do you really put the page together on the server that will be used as productive system?

In that case, your new co-developer will need access to the server (i.e. ftp, ssh, ...) where the site is located at. You can't do that without the old developer knowing about it (except if you share your accounts, which you, as I hope, won't do).

share|improve this answer

The best way to move forward?

  1. Create a private paid repository at github.com and give access to your old developer. Demand that he push the code base there.
  2. Privately fork that project on github and let your new developer access the fork.
  3. When your old developer has finished his changes, and committed them to your github repository, have your new developer merge those changes.

I would also recommend that you use cloudcontrol.com to deploy your application. Using cloudcontrol.com will force your developers to standardize their deployment procedures, and lets you avoid developer lock-in (in the form of non-standard and quirky deployment procedures).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.