Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I am a "one man team" ASP.NET C#, SQL, HTML, JQuery programmer that wants to split workload with two other guys.

Since I never actually thought of possible issue in a team of programmer, there are actually quite a few that came to my mind.

delegating tasks (who works on what which is also very much related to security). I found Team Foundation Service could be helpful with this problem and started reading about it. Are there any alternatives?

security (do now want for original code to be reused outside the project) How to prevent programmers from having access to all parts of code, and how to prevent them from using that code outside of project? Is trust or contract the only way?

share|improve this question

closed as too broad by gnat, gbjbaanb, Simon, Eric King, Kilian Foth Nov 8 '13 at 13:40

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

What did you try? See the project-management tag and How to manage a Closed Source High-Risk Project?. –  CodeCaster Nov 8 '13 at 12:32
Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask –  gnat Nov 8 '13 at 12:36
thanks for sharing resource. Like I said, i am one man team, wanting to become a part of team. What can I try? Do i need to try and fail, and then ask a question, or is it ok to research and get pointers, so I know what to ask and where to look. –  John Nov 8 '13 at 12:44

2 Answers 2

up vote 6 down vote accepted

Delegating tasks is difficult, in a context where the whole project was written by a single developer. "My project" becomes "our project", which may cause a lot of pain if the project is successful. If the project fails, the situation is not much better, because it can cause each member of the team blaming others.

Essentially, you need:

  • People with communication skills and willingness to cooperate. This one is crucial. Some programmers are totally unable to work with other people. There is nothing you can do in this case. A team where one of the members is unable to work in a team would inevitably be a nightmare for everyone.

    If in the new team, there are only programmers who are able to work with other people, they'll find a way to communicate. I don't say there will be no problems, but it would be workable enough.

    There are billion ways for a person unable to cooperate to screw a team. Here are a few ones:

    1. "I find the idea of my colleague stupid, so I won't work on this part of the code source."

    2. "I've rewritten the whole code base during weekend to match it my own style."

    3. "It's his fault."

    4. "It's not my code. I'll write the function which does the same thing myself."

    5. "It works on my machine."

    6. "Why should I do it? It doesn't belong to the part of the project I'm working on."

    7. "I'm the only one who work here."/"I do all the hard work here."

    8. "I'm the most talented guy in this team. Other members should shut up and listen when I talk. If their opinion doesn't match, they're wrong."

    9. "It's him who broke my code, so it belongs to him to fix it. I don't care about all this TDD stuff: the one who breaks stuff is the one who fixes it."

    10. "I don't care if I broke somebody else's code. They had to unit test it beter than that."

    11. etc.

  • Leadership. A team may be solid enough, but from time to time, leadership would be required. For example, what if two talented developers suggest different solutions to a single problem, both solutions being perfectly valid, while being opposite? Or what if one programmer wants to use tabs and another one suggests spaces?

  • Tools and processes. This is a minor point compared to people and leadership, but may affect how the team works.

    The presence of a bug tracking system (FogBugz, Jira, etc.) or a version control (Git, SVN, TFS, etc.) is mandatory (well, those are mandatory in a team of one developer in any case).

    Scrum, XP, Waterfall or anything else may also help in organizing the project (again, a one-developer team should have this too).

    Nightly builds or, better, continuous integration would also mitigate all the pain related to broken builds.

    TDD or, more generally, any correctly done testing is a must-have in order for individuals to avoid breaking their colleagues' stuff. Of course, tests should run within continuous integration.

    Configuration management, often omitted in a one-person team, becomes essential in a team of two or more.

    Linters and style checkers may be a good idea. For example, a PEP 8 pre-commit hook for Python code would ensure that everything committed matches the coding conventions. While it's not crucial for a team of one, it becomes essential when several developers work together.

As for the security, I already answered this question before. If you don't trust a person, don't hire him.

share|improve this answer
very useful stuff. If you know someone, you are able to trust him/hire him. If you don't know the person, trust is a very subjective thing. –  John Nov 8 '13 at 12:48
How do 1-11 relate to lack of Social Skills? Depending on the circumstances I would judge some of those points to be examples of very advanced social skills. –  paulkayuk Nov 8 '13 at 13:39
Good point. Should I say: "lack of collaboration" instead? I understand that the term social skills is not the good one here, but I can't find the one which would describe the context correctly. –  MainMa Nov 8 '13 at 14:19

If the code is organised in truly independant pieces, then restricting access is easy - set up security in your favourite SCM tool (TFS is one, Subversion, Mercurial and git are others) and only allow some people access to the repositories or subdirectories within a repository that they need access to. If there are dependencies, try to put them into a common repository so only those parts need to be shared.

The rest of it is down to your management and leadership skills.

share|improve this answer

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