How to not take risks with new collaborators?

Question

My team is going to add new team members and my manager doesn't want to take any risks. I don't think it's a large problem but my manager is concerned that a new programmer would sabotage and accidentally destroy parts of the code or the data e.g. cause data disaster. I say that probability is not very high but still I've been told that it's important to limit the rights of what new collaborators can do.

But this is not practical and we can't eat the cake and have it - adding a collaborator to source control gives the new collaborator access to all the source code and even if there was a way to only let a new member in to parts of the source code (we're using bitbucket for source control) it still wouldn't work since technically the whole project is usually needed to build it so one can't just take a part of the code and expect it to work and able to build on independently.

We're using Google App Engine and nor is it a working idea to create a clone of the app that my collaborator can build on.

I said that we are not the first ones with this problem and that a solution that works for someone else should work for us but my manager seemed not satisfied with that answer.

Can you comment on my situation or give concrete advice what could be done about the "problem" / scenario since it's just a scenario that a newly added developer accidentally deletes the whole datastore, but we don't want it to be possible.

Answer 1

Using network credentials is your first line of defense - if the new person can't access a resource (web server, database server, authentication service etc) they can't compromise it.

This also means that you don't store passwords for your databases and other servers in source control or any place that a new person can access.

In terms of source control - since you are using it, you are protected. If the new person deletes all the code and commits - you just roll back.

As for databases - as any DBA will tell you, having good backups and restore strategy is your protection against many issues.

However, these are all technical means to mitigate a social problem. The fact is that your manager shouldn't be hiring people he can't trust. Having a penalty clause in the contract of this person is the right solution to this issue.

---

Update - it occurs to me that all of the above will not protect your company from you or one of your existing colleagues with full access to everything fat fingering a deletion of your full datastore. How has your manager mitigated against that???

Answer 2

Limiting access to source control does not make sense - thats why you have source control. If the new person makes a bad commit, just revert to a previous version.

I think good automatic tests and frequent code reviews with new team members are much more valuable. And if your boss is concerned about data loss on production systems, you shouldn't let developers have direct unrestricted access to those anyway.

Answer 3

Have a procedure to make sure they are paired with an experienced team member for certain operations the first few times. Source control and backups will protect you, but it can still cost several hours of labor.

As to the breaking things, the higher your score on the Joel test the easier it should be for them to correctly build and deploy the first time they have to.

Answer 4

Disaster Recovery Plan. New hires, disgruntled old hires, innocent errors, and problems with Google happen. If we could prevent errors from happening 100% of the time (Pin-headed managers love absolutes.), we wouldn't have backups.

Auditing - your system should know who deleted all the data.

Hiring Quality People - get references and do background checks. Most professionals lose sleep at night worring about losing code and accidentally causing problems with their data and not finding ways to ruin their careers. Your boss should focus on doing his/her job better when hiring.

Testing and Staging Areas - I don't know about Google App Engine, but this is unacceptable and not common. If it is a cost issue, your boss needs to get back to doing his job and justify it based on the obvious risks. Don't test or code on production systems and data.