Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
What risks is your boss trying to mitigate? – Oded Feb 28 '12 at 13:53

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???

share|improve this answer
Thank you for the extensive answer. The manager has worries while I think we are seeing ghosts and making unlikely scenarios - most likely the scenario will not happen and therefore most likely we are investing in something that will never get used. We didn't have a plan how to mitigate against mistakes / sabotages from new collaborators and I think that which is suggested in other answer, to team the new collaborator with someone more experienced in the beginning, is reasonable. – Programmer 400 Feb 28 '12 at 14:22
@NickRosencrantz That will not prevent them from sabotaging (that is, if they are willing to sabotage) – BЈовић Feb 28 '12 at 14:44

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.

share|improve this answer
Thank you for the answer. With Google APp Engine there are roles as "Owner", "Developer" and "Viewer". If a person is not owner or developer he can only view so collaboraters need to be owners or developers. We registered the boss as owner and myself as developer and now we / the boss are/is worried that new collaborators technically can sabotage the system or program it to make a wrong payment. But I think we are seeing ghosts and this is still just a scenario. Thanks again for the answer. – Programmer 400 Feb 28 '12 at 14:20
From what I found out from Google, those roles are defined for the administration console. Does a new developer really need access to that console in production? Do you have some kind of development environment where to deploy new versions of the app where it doesn't matter what a developer does? – ftr Feb 28 '12 at 14:57
Thing is, to test the program one really needs the production environment since it sends reports and depends on data that is only in the production site. I suppose we could make a staging area to which a new developer deploys so the production environment isn't touched and the new collaborator only gets access to the source code and the staging environment that replicates that live datastore. I think that will be a step towards a solution. Thank you for the conitnued discussion. – Programmer 400 Feb 28 '12 at 15:19
@Nick Rosencrantz In my opinion, such a staging area is definetely the way to go. If the developer never goes near production, code reviews and good QA should rule out what your boss is afraid of. – ftr Feb 28 '12 at 15:28

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.

share|improve this answer

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.

share|improve this answer

Your Answer


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

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