How to manage virtual software developers without putting code at risk [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-3
down vote
favorite
Me and a friend of mine are thinking of hiring 3-5 people to develop applications for us.
Our concern is how safe will our code be.
We already have some of the code that we started ourselves, and we will like to keep it safe. We are thinking of using GitHub repositories for the team to use to develop the application; this way they all have access to the code and are able to run the application and see results.
I have done this before with one other person and in order for the application to work well and for the person to see their results and what has been done, they need the ENTIRE code for the application on their computer.
This is something that worries me and my friend because what if the people we will hire decide to keep the code after they are done or decide to duplicate it and whatnot.
How do we manage a five-man team without putting our code at risk?
Please help me, we are using Google and no straight forward answers have come up so far.
team teamwork
closed as off-topic by jmort253♦ Mar 12 '14 at 1:08
- This question does not appear to be about the workplace within the scope defined in the help center.
add a comment |Â
up vote
-3
down vote
favorite
Me and a friend of mine are thinking of hiring 3-5 people to develop applications for us.
Our concern is how safe will our code be.
We already have some of the code that we started ourselves, and we will like to keep it safe. We are thinking of using GitHub repositories for the team to use to develop the application; this way they all have access to the code and are able to run the application and see results.
I have done this before with one other person and in order for the application to work well and for the person to see their results and what has been done, they need the ENTIRE code for the application on their computer.
This is something that worries me and my friend because what if the people we will hire decide to keep the code after they are done or decide to duplicate it and whatnot.
How do we manage a five-man team without putting our code at risk?
Please help me, we are using Google and no straight forward answers have come up so far.
team teamwork
closed as off-topic by jmort253♦ Mar 12 '14 at 1:08
- This question does not appear to be about the workplace within the scope defined in the help center.
4
cross-posted at Stack Overflow, at Programmers and Workplace
– gnat
Mar 9 '14 at 6:46
Hello user, please don't cross-post your questions across different Stack Exchange sites unless you tailor them to the site. Copy/pasting a question word for word just creates noise.
– jmort253♦
Mar 12 '14 at 1:07
This question appears to be off-topic because it is about programming practices and not the workplace.
– jmort253♦
Mar 12 '14 at 1:08
First of all, one does not manage developers, one may direct developers, lead developers. Then, if you hire a team, you will need to trust these people.
– Nicolas Barbulesco
Jun 20 '15 at 15:30
1
@jmort253 - To the contrary, I find that this question is in fact much more about working with people than about technical practices.
– Nicolas Barbulesco
Jun 20 '15 at 16:15
add a comment |Â
up vote
-3
down vote
favorite
up vote
-3
down vote
favorite
Me and a friend of mine are thinking of hiring 3-5 people to develop applications for us.
Our concern is how safe will our code be.
We already have some of the code that we started ourselves, and we will like to keep it safe. We are thinking of using GitHub repositories for the team to use to develop the application; this way they all have access to the code and are able to run the application and see results.
I have done this before with one other person and in order for the application to work well and for the person to see their results and what has been done, they need the ENTIRE code for the application on their computer.
This is something that worries me and my friend because what if the people we will hire decide to keep the code after they are done or decide to duplicate it and whatnot.
How do we manage a five-man team without putting our code at risk?
Please help me, we are using Google and no straight forward answers have come up so far.
team teamwork
Me and a friend of mine are thinking of hiring 3-5 people to develop applications for us.
Our concern is how safe will our code be.
We already have some of the code that we started ourselves, and we will like to keep it safe. We are thinking of using GitHub repositories for the team to use to develop the application; this way they all have access to the code and are able to run the application and see results.
I have done this before with one other person and in order for the application to work well and for the person to see their results and what has been done, they need the ENTIRE code for the application on their computer.
This is something that worries me and my friend because what if the people we will hire decide to keep the code after they are done or decide to duplicate it and whatnot.
How do we manage a five-man team without putting our code at risk?
Please help me, we are using Google and no straight forward answers have come up so far.
team teamwork
edited Jul 3 '16 at 8:38
Peter Mortensen
45547
45547
asked Mar 9 '14 at 2:56
user3371326
6
6
closed as off-topic by jmort253♦ Mar 12 '14 at 1:08
- This question does not appear to be about the workplace within the scope defined in the help center.
closed as off-topic by jmort253♦ Mar 12 '14 at 1:08
- This question does not appear to be about the workplace within the scope defined in the help center.
4
cross-posted at Stack Overflow, at Programmers and Workplace
– gnat
Mar 9 '14 at 6:46
Hello user, please don't cross-post your questions across different Stack Exchange sites unless you tailor them to the site. Copy/pasting a question word for word just creates noise.
– jmort253♦
Mar 12 '14 at 1:07
This question appears to be off-topic because it is about programming practices and not the workplace.
– jmort253♦
Mar 12 '14 at 1:08
First of all, one does not manage developers, one may direct developers, lead developers. Then, if you hire a team, you will need to trust these people.
– Nicolas Barbulesco
Jun 20 '15 at 15:30
1
@jmort253 - To the contrary, I find that this question is in fact much more about working with people than about technical practices.
– Nicolas Barbulesco
Jun 20 '15 at 16:15
add a comment |Â
4
cross-posted at Stack Overflow, at Programmers and Workplace
– gnat
Mar 9 '14 at 6:46
Hello user, please don't cross-post your questions across different Stack Exchange sites unless you tailor them to the site. Copy/pasting a question word for word just creates noise.
– jmort253♦
Mar 12 '14 at 1:07
This question appears to be off-topic because it is about programming practices and not the workplace.
– jmort253♦
Mar 12 '14 at 1:08
First of all, one does not manage developers, one may direct developers, lead developers. Then, if you hire a team, you will need to trust these people.
– Nicolas Barbulesco
Jun 20 '15 at 15:30
1
@jmort253 - To the contrary, I find that this question is in fact much more about working with people than about technical practices.
– Nicolas Barbulesco
Jun 20 '15 at 16:15
4
4
cross-posted at Stack Overflow, at Programmers and Workplace
– gnat
Mar 9 '14 at 6:46
cross-posted at Stack Overflow, at Programmers and Workplace
– gnat
Mar 9 '14 at 6:46
Hello user, please don't cross-post your questions across different Stack Exchange sites unless you tailor them to the site. Copy/pasting a question word for word just creates noise.
– jmort253♦
Mar 12 '14 at 1:07
Hello user, please don't cross-post your questions across different Stack Exchange sites unless you tailor them to the site. Copy/pasting a question word for word just creates noise.
– jmort253♦
Mar 12 '14 at 1:07
This question appears to be off-topic because it is about programming practices and not the workplace.
– jmort253♦
Mar 12 '14 at 1:08
This question appears to be off-topic because it is about programming practices and not the workplace.
– jmort253♦
Mar 12 '14 at 1:08
First of all, one does not manage developers, one may direct developers, lead developers. Then, if you hire a team, you will need to trust these people.
– Nicolas Barbulesco
Jun 20 '15 at 15:30
First of all, one does not manage developers, one may direct developers, lead developers. Then, if you hire a team, you will need to trust these people.
– Nicolas Barbulesco
Jun 20 '15 at 15:30
1
1
@jmort253 - To the contrary, I find that this question is in fact much more about working with people than about technical practices.
– Nicolas Barbulesco
Jun 20 '15 at 16:15
@jmort253 - To the contrary, I find that this question is in fact much more about working with people than about technical practices.
– Nicolas Barbulesco
Jun 20 '15 at 16:15
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
6
down vote
First, you shouldn't take any steps that will hamstring your developers from producing the best work that they can. If they need access to everything to properly do their jobs, then that's what you should give them.
Second, it sounds like you're concerned about intellectual property theft. Generally, I have found this to be a massively overblown concern. In the words of Howard Aiken, "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."
Make it clear in the contract that you consider the code closed-source and confidential, proprietary information. After that, just manage the project by removing obstacles and helping your developers succeed.
And hire only people you trust. Do a backgroupnd check if you feel the need. Or hire only people you or people you trust personally know.
– HLGEM
Mar 11 '14 at 21:16
@HLGEM - ...Or trust the people you hire. One way or the other, trust will be essential here.
– Nicolas Barbulesco
Jun 20 '15 at 16:17
add a comment |Â
up vote
2
down vote
Ultimately at least one person needs to be able to perform integration testing. I think about the best you can do towards your stated goal is as follows. Have a trusted team lead who directs development and integrates the methods/components produced by the team members. In other words, only one person has access to the complete repos and they undertake architecture, task assignment, code review, integration testing and check-in. I'm not necessarily saying this will lead to best results, it will likely slow down development considerably and a lot more communication will be required, but you will be able to prevent team members seeing the entire codebase that way.
The other alternative is to somehow keep your "secret sauce" or some critical innovation in the app confidential until as late as possible while most of the other work gets done, and then have a single person integrate that piece at the end. That way you can have everyone working efficiently on the same entire shared codebase for the majority of the development effort and not compromise what is important to you. The risk there is that you may only realize late in the game that major changes are necessary because you only get full requirements visibility once you begin to integrate your innovation.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
First, you shouldn't take any steps that will hamstring your developers from producing the best work that they can. If they need access to everything to properly do their jobs, then that's what you should give them.
Second, it sounds like you're concerned about intellectual property theft. Generally, I have found this to be a massively overblown concern. In the words of Howard Aiken, "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."
Make it clear in the contract that you consider the code closed-source and confidential, proprietary information. After that, just manage the project by removing obstacles and helping your developers succeed.
And hire only people you trust. Do a backgroupnd check if you feel the need. Or hire only people you or people you trust personally know.
– HLGEM
Mar 11 '14 at 21:16
@HLGEM - ...Or trust the people you hire. One way or the other, trust will be essential here.
– Nicolas Barbulesco
Jun 20 '15 at 16:17
add a comment |Â
up vote
6
down vote
First, you shouldn't take any steps that will hamstring your developers from producing the best work that they can. If they need access to everything to properly do their jobs, then that's what you should give them.
Second, it sounds like you're concerned about intellectual property theft. Generally, I have found this to be a massively overblown concern. In the words of Howard Aiken, "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."
Make it clear in the contract that you consider the code closed-source and confidential, proprietary information. After that, just manage the project by removing obstacles and helping your developers succeed.
And hire only people you trust. Do a backgroupnd check if you feel the need. Or hire only people you or people you trust personally know.
– HLGEM
Mar 11 '14 at 21:16
@HLGEM - ...Or trust the people you hire. One way or the other, trust will be essential here.
– Nicolas Barbulesco
Jun 20 '15 at 16:17
add a comment |Â
up vote
6
down vote
up vote
6
down vote
First, you shouldn't take any steps that will hamstring your developers from producing the best work that they can. If they need access to everything to properly do their jobs, then that's what you should give them.
Second, it sounds like you're concerned about intellectual property theft. Generally, I have found this to be a massively overblown concern. In the words of Howard Aiken, "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."
Make it clear in the contract that you consider the code closed-source and confidential, proprietary information. After that, just manage the project by removing obstacles and helping your developers succeed.
First, you shouldn't take any steps that will hamstring your developers from producing the best work that they can. If they need access to everything to properly do their jobs, then that's what you should give them.
Second, it sounds like you're concerned about intellectual property theft. Generally, I have found this to be a massively overblown concern. In the words of Howard Aiken, "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."
Make it clear in the contract that you consider the code closed-source and confidential, proprietary information. After that, just manage the project by removing obstacles and helping your developers succeed.
answered Mar 9 '14 at 5:33
John Feminella
1613
1613
And hire only people you trust. Do a backgroupnd check if you feel the need. Or hire only people you or people you trust personally know.
– HLGEM
Mar 11 '14 at 21:16
@HLGEM - ...Or trust the people you hire. One way or the other, trust will be essential here.
– Nicolas Barbulesco
Jun 20 '15 at 16:17
add a comment |Â
And hire only people you trust. Do a backgroupnd check if you feel the need. Or hire only people you or people you trust personally know.
– HLGEM
Mar 11 '14 at 21:16
@HLGEM - ...Or trust the people you hire. One way or the other, trust will be essential here.
– Nicolas Barbulesco
Jun 20 '15 at 16:17
And hire only people you trust. Do a backgroupnd check if you feel the need. Or hire only people you or people you trust personally know.
– HLGEM
Mar 11 '14 at 21:16
And hire only people you trust. Do a backgroupnd check if you feel the need. Or hire only people you or people you trust personally know.
– HLGEM
Mar 11 '14 at 21:16
@HLGEM - ...Or trust the people you hire. One way or the other, trust will be essential here.
– Nicolas Barbulesco
Jun 20 '15 at 16:17
@HLGEM - ...Or trust the people you hire. One way or the other, trust will be essential here.
– Nicolas Barbulesco
Jun 20 '15 at 16:17
add a comment |Â
up vote
2
down vote
Ultimately at least one person needs to be able to perform integration testing. I think about the best you can do towards your stated goal is as follows. Have a trusted team lead who directs development and integrates the methods/components produced by the team members. In other words, only one person has access to the complete repos and they undertake architecture, task assignment, code review, integration testing and check-in. I'm not necessarily saying this will lead to best results, it will likely slow down development considerably and a lot more communication will be required, but you will be able to prevent team members seeing the entire codebase that way.
The other alternative is to somehow keep your "secret sauce" or some critical innovation in the app confidential until as late as possible while most of the other work gets done, and then have a single person integrate that piece at the end. That way you can have everyone working efficiently on the same entire shared codebase for the majority of the development effort and not compromise what is important to you. The risk there is that you may only realize late in the game that major changes are necessary because you only get full requirements visibility once you begin to integrate your innovation.
add a comment |Â
up vote
2
down vote
Ultimately at least one person needs to be able to perform integration testing. I think about the best you can do towards your stated goal is as follows. Have a trusted team lead who directs development and integrates the methods/components produced by the team members. In other words, only one person has access to the complete repos and they undertake architecture, task assignment, code review, integration testing and check-in. I'm not necessarily saying this will lead to best results, it will likely slow down development considerably and a lot more communication will be required, but you will be able to prevent team members seeing the entire codebase that way.
The other alternative is to somehow keep your "secret sauce" or some critical innovation in the app confidential until as late as possible while most of the other work gets done, and then have a single person integrate that piece at the end. That way you can have everyone working efficiently on the same entire shared codebase for the majority of the development effort and not compromise what is important to you. The risk there is that you may only realize late in the game that major changes are necessary because you only get full requirements visibility once you begin to integrate your innovation.
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Ultimately at least one person needs to be able to perform integration testing. I think about the best you can do towards your stated goal is as follows. Have a trusted team lead who directs development and integrates the methods/components produced by the team members. In other words, only one person has access to the complete repos and they undertake architecture, task assignment, code review, integration testing and check-in. I'm not necessarily saying this will lead to best results, it will likely slow down development considerably and a lot more communication will be required, but you will be able to prevent team members seeing the entire codebase that way.
The other alternative is to somehow keep your "secret sauce" or some critical innovation in the app confidential until as late as possible while most of the other work gets done, and then have a single person integrate that piece at the end. That way you can have everyone working efficiently on the same entire shared codebase for the majority of the development effort and not compromise what is important to you. The risk there is that you may only realize late in the game that major changes are necessary because you only get full requirements visibility once you begin to integrate your innovation.
Ultimately at least one person needs to be able to perform integration testing. I think about the best you can do towards your stated goal is as follows. Have a trusted team lead who directs development and integrates the methods/components produced by the team members. In other words, only one person has access to the complete repos and they undertake architecture, task assignment, code review, integration testing and check-in. I'm not necessarily saying this will lead to best results, it will likely slow down development considerably and a lot more communication will be required, but you will be able to prevent team members seeing the entire codebase that way.
The other alternative is to somehow keep your "secret sauce" or some critical innovation in the app confidential until as late as possible while most of the other work gets done, and then have a single person integrate that piece at the end. That way you can have everyone working efficiently on the same entire shared codebase for the majority of the development effort and not compromise what is important to you. The risk there is that you may only realize late in the game that major changes are necessary because you only get full requirements visibility once you begin to integrate your innovation.
edited Mar 9 '14 at 7:31
answered Mar 9 '14 at 7:22
Brad Thomas
2,744820
2,744820
add a comment |Â
add a comment |Â
4
cross-posted at Stack Overflow, at Programmers and Workplace
– gnat
Mar 9 '14 at 6:46
Hello user, please don't cross-post your questions across different Stack Exchange sites unless you tailor them to the site. Copy/pasting a question word for word just creates noise.
– jmort253♦
Mar 12 '14 at 1:07
This question appears to be off-topic because it is about programming practices and not the workplace.
– jmort253♦
Mar 12 '14 at 1:08
First of all, one does not manage developers, one may direct developers, lead developers. Then, if you hire a team, you will need to trust these people.
– Nicolas Barbulesco
Jun 20 '15 at 15:30
1
@jmort253 - To the contrary, I find that this question is in fact much more about working with people than about technical practices.
– Nicolas Barbulesco
Jun 20 '15 at 16:15