Switching developers mid-game development

We began development with a couple of programmers we hired on Elance. Long story short we’ve got over a year of development done and now all progress has completely ceased at what appears to be the very end of the job being complete.

We’ve come to the conclusion that we need to have a team take over the final stages of development on our app, which will (hopefully) be the team that we work with on all future updates and maintenance moving forward. However we have no idea where to start with this takeover process. What should we be looking for in the developers that are going to pick up where the last one left off? What exactly do we need from our current guys to hand over to the new team?

We’ve definitely learned several lessons the hard way on this one already so any advice on what our next steps should be moving forward would be greatly appreciated!

Yes well I guess the main question is what all do we need to provide the new team in regards to files etc. for them to completely takeover and finish development? How realistic is this that someone else can step in and pick up where another code left off? We have not had the code reviewed (another lesson learned) so would that need to be the first step before we go about trying to find someone for the job?

The new team would need all of the code, assets, project files, documentation, and anything else the original team created. There's no way for you as a non-developer to cherry-pick what the new team needs or doesn't need. If you want to them to finish the project then you should give them everything so they have everything at their disposal.

A code review will give you an opinion on how well the the implementation has been created, but at this stage, it is what it is. Unless you're prepared to accept the opinion (and possibly fact) that the work is terrible and major pieces or all of it needs to be thrown out, your goal is likely to just finish it given what's already there.

It is certainly very realistic for a new team to pickup a project where another left off, but there's going to be some period of time where all they're doing is learning what the current code is doing. Depending on how well the original team did their job, that could be fairly short, or fairly long. Either way, it's possible. Zillions of developers do it all the time when jumping onto a new project.

Your first step would be getting everything possible from the original team, along with a rough assessment of what's done and not done. In the job posting, you'd mention that there's an existing codebase, roughly what needs to be done, and your qualification requirements, etc. Given that the dev team is being entirely replaced, it's a messy set of circumstances, so it's possible you're not going to know the probable outcome of collaborating with a particular new team since there are many unknowns to you regarding the new team, and to the new team regarding the old team's code. When vetting the new team, you can request an NDA be signed and pass along the entire project so they can evaluate it and give their opinion on the state of the project and their projections.

Something that is just as important as getting the files to the new team is figuring out what went wrong with the previous team. This may mean looking at yourself and asking some very hard questions. These questions could include:

Did the other company underestimate what was necessary, and were we willing to take their

Did we change our requirements during development?*

Where did communication break down?

What was the root cause of why things failed? Ask why at least five times, because it's more than just "the development team didn't do what we asked them to."

*By change, I mean change AT ALL. If you changed your requirements even a little bit, that is generally the beginnings of major failure when hiring someone on the cheap via outsourcing. If you're hiring someone on elance, I'm presuming you did it to save money, otherwise you would hire someone near you (or referred to you by a colleague whose opinion you respect) and pay good money to ensure you got a quality project and good outcome.

As for the code that you have now... it might suck. The new team may have to seriously change it around. It sounds like you are inexperienced with software development, so I would *strongly* encourage you to pay the money necessary to get a quality developer to help you learn. And be sure to treat that developer in an appropriate way; for instance, if it's a hired contractor outside of your company, treat them as such. You cannot change requirements on them without expecting to pay more money. You cannot have unlimited bug fixes / small tweaks, since the contractor needs to move onto other projects.

Sorry if the tone is a bit incriminating, but the "long story short" phrase of your first post seems very vague and likely there's a huge story that is at the root of whether you will be successful in software development or not.

Would you be willing to write a blog post about what that "long story" consists of, at least partially? The names can be changed to protect the innocent/guilty, but being able to summarize why things went off the rails can both help you, and will help the next team you work with have a better idea of what to expect.

Reply here and I'm happy to talk to you more about these things - but writing that blog post first and posting a link would be *fantastic*