How to manage virtual software developers without putting code at risk [closed]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
-3
down vote

favorite
1












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.







share|improve this question














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.
If this question can be reworded to fit the rules in the help center, please edit the question.








  • 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
















up vote
-3
down vote

favorite
1












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.







share|improve this question














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.
If this question can be reworded to fit the rules in the help center, please edit the question.








  • 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












up vote
-3
down vote

favorite
1









up vote
-3
down vote

favorite
1






1





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.







share|improve this question














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.









share|improve this question













share|improve this question




share|improve this question








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.
If this question can be reworded to fit the rules in the help center, please edit the question.




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.
If this question can be reworded to fit the rules in the help center, please edit the question.







  • 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




    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










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.






share|improve this answer




















  • 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


















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.






share|improve this answer





























    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.






    share|improve this answer




















    • 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















    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.






    share|improve this answer




















    • 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













    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.






    share|improve this answer












    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    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

















    • 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













    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.






    share|improve this answer


























      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.






      share|improve this answer
























        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.






        share|improve this answer














        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Mar 9 '14 at 7:31

























        answered Mar 9 '14 at 7:22









        Brad Thomas

        2,744820




        2,744820












            Comments

            Popular posts from this blog

            What does second last employer means? [closed]

            List of Gilmore Girls characters

            Confectionery