Moving from one man project to team project in the future. What should I be doing now in preparation and what can wait?

Question

To elaborate I am interested in knowing what people think you need to put in place while still a one man project (team source control, documentation, builds etc) and what things don't need to be done until that point when the second person comes onto the project.

Anyone with any experience of moving through this scenario, their insights will be appreciated.

Answer 1

What I've learned. (I tried a different order. I was wrong. This is the order in which things become relevant.)

1. Put everything into source code control. Use something everyone has access to and start right now. No exceptions. No delays. No excuses.

2. Create a QA/Test area that is totally separate from your personal "working" or "development" environment. At least a separate user id. Ideally on a separate VM.
   Completely separate. No possible overlap with your current working environment.

3. Stop testing beyond unit test in your own working environment. Code and unit test you do "as yourself". All other testing (integration, performance, whatever) you do on the separate VM. Never test as yourself. Always test as a separate QA user. Ideally on a separate VM.

   "Works for me," is a bad thing to have to say to your team member(s). Very bad. You need to figure out what they're doing wrong. Several times a day.

4. Plan to write down everything. Use a plain-text markup tool (RST or Markdown or something) so that all documentation is plain-text in the version control repository. A tool can create HTML pages (i.e., Docutils for RST) or PDF's or whatever seems best. Don't use proprietary document formats (i.e. MS-Word). They may not play well with some source-code control systems.

5. The first things you need to write down are the following.

   • How to create a working development environment. When in doubt, create a Virtual machine and do the entire operation on that virtual machine. Be sure that the steps really work and the documentation is clear. Actual lines typed at the actual command line kind of clarity.

   • How to run the unit test suite. Again. Be sure that the instructions work and do not require thinking. "Type this:" "Confirm that:" kind of stuff. It's not that your team members are stupid. It's that you don't remember what you're assuming unless you write it all down.

   • How to run the integration test suite.

   Don't waste a lot of time describing the architecture or the design principles. You need to get someone up and running first. You can explain stuff later.

6. The next things to document are the user stories. And the test cases that support those stories. And the data fixtures required for the test cases that support those user stories.

   You will be sharing this. It goes under source code control.

7. Eventually, you can document the other 4 views.

   • Logical view is helpful stuff to document. Pictures are acceptable here. This tends to evolve rapidly, so don't spend time capturing the legacy information. Work out a way to cooperate with your team member(s).

   • Process view is often helpful. Depends on the overall application how important this is.

   • Development view -- modules, libraries, frameworks, etc. -- is often described informally. A picture might help, but it's notoriously hard to make this complete enough that someone can pick up a document and make heads or tails of it. Even long-established, very public projects have library documentation that is simply ignored. (Leading to a lot of Stack Overflow questions.)

     Besides being acceptable to be informal, this tends to change rapidly.

   • Deployment information. Servers. IP addresses. Database credentials. All that stuff must get written down. Eventually.

Answer 2

Tools and methodology

What is needed to collaborate successfully and to be productive?

• Identify parts/components of your project: Distinguishing clearly between different parts (database, data access layer, web site, service, API, test projects, build scripts, ...) and environments (dev, staging, production), and naming them consistently has an impact on your oral and written communication (documentation, project names, ...)
• Use a source code management system (just in case you don't yet). Think about how to use branching with your project and setup.
• Automate your builds - make it as easy as possible to set up an environment from your source repository.
• Test projects are a must on big projects, at least for the more complex projects.
• Use staging environment(s) where your project is ready to be used. Also, create and maintain sample data for an automated staging setup.
• Use a bug tracking system which can help prioritizing and planning the development, and also serves as a memory for past bugs and how they were resolved.
• Document each part of your project, some more than others. I personally like: Overview - Architecture - Dependencies - Configuration - Common problems (from here). Sometimes less is more - in order to not let your documentation get outdated, it's better to be concise and let documentation become a part of your everyday activity.

Management / teamwork

... or anything else on the interpersonal level

• Define your expectations of the other developer. Be reasonable, nobody's likely to bring in the same involvement and passion as you do - at least not right from the start. Communicate what you expect and what not, define your and the other one's responsibilities. Not everybody is an engineer, architect, developer, dba and sysadmin, but if that's what you're looking for, choose the right person or you will be disappointed.
• At first, define tasks precisely, and review and discuss the results. Gradually, start less and less micro-managing. The idea is to build up trust and to increase responsibility.
• Plan your project, set goals for your project and for your team for the next year. Write it down and check it later, this will give perspective. Those goals may or may not be communicated to others (as long as they are goals you need to achieve, not others), it can simply be your own checklist.
• Take a day to prepare and plan the first month (or two/three months) of your new developer. I find it extremely motivating when working with well prepared people. Nobody should get the impression that his/her time is wasted.
• Let go. It's your baby, it should become somebody else's, too. Allow the other one to become an expert better than you, at least in some parts of the project. This means actually you succeeded.
• Listen - if you hired her, she's got something to say. Be ready to learn.
• Be ready to share your knowledge and experience (and therefore time - be patient).
• Mistakes will be made, it's how they're handled and what everybody's learning about them what counts.
• Allow time to learn and experiment

Book references

I'll list some of the commonly mentioned books that I've actually read and I think are worth reading, for a more detailed description or for more books you may want to check out some of the questions on SO asking exactly for that, like this or this question.

Those books really are worth reading in respect to teams, organizations, and programming projects:

• Peopleware
• Mythical Man Month
• Software Estimation, Demystifying the Black Art

None of those are practical guides of how to implement methodology X (except Software estimation, this books helps you choose an appropriate estimation process). Of course, books more focused on programming itself like Code Complete are also very enriching.

Answer 3

I will talk from the experience, but keep in mind that everyone is different. These things are not universal.

One thing is to let it go personally. This project is something you lived with and lived in for 18 months - you would naturally want every change to be like you would do it. Give a buffer for a colleague to make mistakes, to learn. Create a room for them to be useful. And keep in mind it might not happen right away. Also it would be great if there is something, a part of the code they can feel they succeed in improving or creating, that feels like success in a short period of time. Patience and tolerance has a good pay off rate here. Do not try to micromanage, and if you want to criticize, to say "you are wrong", make sure you have a merit, you can prove it, it is not a "religious" fight.

Another key issue is to find the right person for you. Ideally it is better to find someone smarter than yourself. It is subjective and relative, but if you feel a person has some knowledge and skills you don't have, it is for the best. It will be a mutually rewarding collaboration.

There are two ways it can go - the colleague will be a drag, and you will end up redoing what he or she did, or the skills of two of you will multiply, not just add up, and you will really appreciate working together.

On a topic of "clean, fast, reusable code" - I suggest on an interview, ask to write a small micro-kernel/service manager and/or job executor. See how pluggable components are specified and configured. Doesn't have to be finished, it is a thought that counts. And also you will quickly learn people who know well how to do it will want decent money ;-) Good luck!

Answer 4

My take: Start with document your internal project's architecture for someone... who is not aware of it. Try to explain which assumptions are in place and when/where you diverted from common practices and why.

Build automation: Great idea, may I add configuration automation for a dev machine. The easiest it is to build the more it will be (so more/faster testing deployment).

Another idea (it helped me a lot once): Ask the new developer to do some clean-up small scale tasks in different areas of your code base, so that he will get accustomed to the layout tools etc. One good idea is to remove obscure areas that might add confusion later on (example: if you used emmm python for two lines of a shell script somewhere and your project is based on java, ask those two lines to be rewritten in java so that the developer #3 will need to know less in order to work)

Answer 5

I would focus on automating everything which require manual work, thus can be screwed up by an inexperienced person. Which, based on your brief comment above, includes the following:

• install version control and replace the manual backups with automated ones,
• set up automatic deployment as much as possible (as the minimum, write a script to deploy via FTP rather than doing it by hand.

If you fail to do these, either you will get chained to do these tasks forever, or (some of) the new guy(s) will inevitably screw up something sooner or later.

The other important task is, as @dimitris noted, documentation. @S. Lott added much more detail on this, so just +1 to him rather than repeating :-)

Answer 6

Here are some thoughts, partly based on personal experience:

• Document your project. Design specifications, diagrams, manuals and comments will help the new employee get up to speed. Explaining a complex system only verbally can prove slow and frustrating. Documentation is frequently neglected in one-man projects. Make sure yours is an exception.

• At first, concentrate on API-/core-level code yourself, while giving the new employee some "application layer" work or bug fixing to gradually familiarize them with the code. Generally, start out with easier, yet meaningful and thus rewarding tasks.

• Communication is important. Be responsive to the new employee's questions, comments and ideas. Explain why you think an idea is not good if you do. A fresh pair of eyes can spot room for improvement surprisingly well. If your new employee is a decent one, he can peer review your code and eventually participate in architectural decisions. Discuss, bounce ideas off each other. That is one of the greatest benefits of having a co-worker on your project.

• Define responsibilities clearly, once you know what kind of tasks your new team member is up to. Establish documentation practices and coding conventions to keep things smooth.

• Use a revision control system. Maintain a logical source file layout and build discipline.

As for the interview - I'm not a big fan of artificial coding tests or trick questions, unless you wish to try the candidate's stress-enduring ability. Even the smartest of problem solvers can lock up in such a situation. The qualities you'll be looking for, among others are: honesty, professional capability, technological knowledge/insight, enthusiasm and mutual compatibility. Work atmosphere can mean a great deal; it is inadvisable to pick a teammate you don't like. Place your questions right and do some informal discussion to get a good picture of your candidate. Good luck!

Answer 7

Technology

If you are bringing in someone else as a developer there are three key things I'd recommend having up and running before they start.

1. Source control
2. Issue tracking
3. Continuous integration

If these three things are up and running properly you'll eliminate about 75% of the common problem that occur when you bring on a new team member. The point of these pieces of technology is to take a lot of what is happening only in your head and get it out where your team member can interact with it.

Source control makes sure you are both working on the same thing. Issue tracking helps you both keep track of what needs to be done and will make it easier for you to know what they are working on and accomplishing. Continuous integration and testing will help make sure that you have a repeatable build process and that new improvements aren't breaking other parts of the code.

Pragmatic Programmer has some pretty good books on this. Here are a few I'd recommend. They have other similar titles based on what programming language you are using or what version control you want to use:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http://www.pragprog.com/titles/auto/pragmatic-project-automation

Personal

Often times the difficulties you will face are less on the technical side of things and more on the learning to let go side. It can be hard to give someone else control over aspects of the project--particularly if you are use to doing it all yourself and making every single decision. You will save yourself some grief if you can find an area where you can have the new person work with a reasonable amount of freedom at the beginning so you can develop a foundation of trust. If you hire a good person, the main thing you'll probably be learning is how to trust the other person to do good work even if all of their individual decisions aren't the same as what you would have made.

You want to give your new hire the freedom to solve problems in the way that works for them while keeping safeguards in place so you can catch problems early on.

Answer 8

These points are most important in my opinion:

1. Read over crucial parts of your code and make sure they are easy to understand. Use comments or intuitive function and variable names.
2. Make it easy for the new person to submit code.
3. If it's not trivial, make a README file that explains all necessary step for the new developer on how to setup the development environment. Alternatively closely assist in setting up this environment.
4. Give the new developer very clearly defined tasks when working on this new project. In my opinion these tasks should involve new but simple functionality. Clean-up tasks don't make much sense in my opinion as the new developer first has to get used to your coding style and those habits in it, even if they are bad. Cleaning up or even refactoring are jobs that need to be done by people who know the code.
5. Make clear what the process is for submitting code. (E.g. submit only stuff that compiles.) But don't be too strict, this can be frustrating at the beginning.
6. Have a document with coding conventions ready. It can be really frustrating to guess what the other ones coding conventions are.
7. If the app is complex, have some documentation ready explaining the architecture. Or explain the architecture to the new person using flow charts or something similar. You don't want to have the new developer waste too much time on reverse-engineering your project.
8. If the new developer is supposed to do deployments himself, have an ordered checklist ready explaining all necessary steps needed to deploy.

And last but not least: get a version control system. Subversion is just fine. But be sure not to add those Eclipse files (or whatever) that are user-specific and therefore constantly chaning. They make you waste hours. Don't hesitate to ask on Stackoverflow if you have problems with it.