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, no registration required.

At my job, I'm currently a programmer, but in the next few weeks I'll be taking control my own project. I was wondering if anyone else here has been in the same situation, and if so, what advice you can offer to help me be able to better run my project. Experience in dealing with contractors would be greatly appreciated.

A little more info:

  • Project will have 3 people including myself, with extra people coming in when needing testing.
  • The project has been programmed mainly by 2 people
  • I would like to contribute to the programming as I like doing it and think I can add to the program, but am afraid of how the contractors will react. I don't want to create bad feelings which may harm the project.


Forgot to mention that I'll have to be picking up communications with customers to make sure their needs are met. Any advice on talking to customers cold would be greatly appreciated.


This is not a new project, I'm picking it up around version 6. Sorry that I didn't make it clear before.

share|improve this question

2 Answers 2

up vote 7 down vote accepted

It is very difficult to lead and write code at the same time. Generally speaking, one of two things could happen:

1) You micro-manage the contractors and they resent it (as you mention)
2) You get lost in programming and lose the big picture

Some tips that may keep you in good standing with both groups:

  • Articulate the standards you're looking for in the beginning. Work with managment to define the spec., and don't stray from it.

  • Meet the commitments you make. This applies to commitments you make to management and to your developers.

  • Don't over-commit yourself. Keep an eye on your ambition, and ego and make sure that you don't find yourself in a place of disappointing everyone. The honest hard truth in the beginning is often better than the letdown of false hopes.

Some general management tips (not sure if this applies to you) - Review the contracts that each contractor has. What are the terms each one has?

  • Management will likely expect you to audit and verify the hours/time put into the project.

  • Meet with the team regularly, and keep an open dialog to keep them on track.

  • Create a process to handle code reviews, QA and testing. Each person has a responsibility to the process. The Project Lead must make sure there are no "code cowboys" in the group and reign them in if there are.

share|improve this answer
Any suggestion for processes that may help, especially when coming into an existing project? I know there will probably be some processes established already, but maybe they can be improved on, or new ones added to help. –  DoctaStooge Oct 22 '10 at 16:02
DoctaStooge - Check the answers to this question for process examples: programmers.stackexchange.com/questions/13902/… –  LamonteCristo Oct 22 '10 at 16:13

I can share with you what I usually do when I'm in your position.

I take a "project startup" meeting where we discuss the technical architecture of the software being developed. We decide roles and assign tasks and priorities.

I, being the project leader, usually take care of creating the abstraction layer (interfaces, facade, contexts, etc) so other developers have a common base upon which they can write their own code, implement methods, etc.

I usually (but it could be someone else) write unit tests in a TDD approach while the programmers implement the methods. They do frequent commits to our SVN repo so I can unit-test their code constantly and see if there are problems and such. I also take care of filling out bug reports on our bug tracking system at the end of the day.

Another task I attend to is review the code and look for antipatterns, bad practices and such. I talk to the developers in a as friendly as possible manner, point their errors and suggest ways to improve. Code quality must stay high throughout all the development.

When the development becomes mature, the software will be human-tested and more bug reports will be filled. Unit tests will continue to play their role of course.

This is just my experience anyway, it could be right or wrong or somewhere between.

share|improve this answer
The thing is, I think the software should already be considered mature. I know this isn't always the case, but it is on version 6, and supposedly is a product line (I haven't seen enough documentation to say whether it is or not). I don't necessarily want to come in and change things if they are working. I want to ensure that my customers would get what they need with as little changes as possible (unless it were necessary of course). –  DoctaStooge Oct 22 '10 at 15:53
Well you never mentioned you are inheriting an already existing project which is at his sixth incarnation. I thought you were starting a new project from scratch. –  Matteo Mosca Oct 22 '10 at 15:55
Yea, I just realized that I forgot that part. Have you ever picked up a project during its life-cycle? If so, how easy/hard is it? What can be done to help keep impact to a minimum? Aside from talking to the old project lead and learning as much as I can of course. –  DoctaStooge Oct 22 '10 at 16:00
This is the path I used to move from Programmer to Project Lead. Basically be the guy or gal who everyone comes to when new problems or ideas appear. To do this you probably need to spend significant time outside of work acquiring the knowledge to be the goto-guy/gal. –  ARKBAN Oct 22 '10 at 16:03

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.