Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are wanting to have developers build an in-house payroll and time sheet application using symfony2/doctrine2.

We are simply at conceptual stage at this point and this will be our first time and getting developers to build an application for our company. Hence, it is very important to us that we provide the most valid and important information to what will be our new developer team.

What documents or tools should we provide to the new team to maximize the odds of success with the project and help the developers be productive from day dot?

share|improve this question
"build an in-house payroll and time sheet application"? Why not buy one. It might be far cheaper. Seriously. Why build a commodity item like this. It can't be for reasons of competitive advantage. "maximize the odds of success" is usually done by purchasing a proven solution. Why build when you can buy? – S.Lott Dec 13 '11 at 0:45

First, I'm curious as to why you're pigeon-holing yourself with symfony2/doctrine2 - is this due to legacy systems? If not, I'd suggest having your potential developers sell you on tech stacks, not the other way around.

If I walked into a meeting where the following was already prepared, I'd leave that room with a big smile:

  • An executive summary. There should be a mission statement somewhere in here. A single sentence that defines the objective of the project. This will not only help your developers keep the end goal in mind, but will also help the design team while developing features (should x actually be a feature of the system?)
  • Subsystem design (high level). Does your application contain logically modular systems? If so, break it up (these could be seen as milestone deliverables).
  • Prototypes. Use programs like Pencil (free) or Balsamiq (commercial) to mock up what you want in your application.

Of course, things will always change, so while there should definitely be much though put into each of these points, you should definitely not come away thinking that the design is set in stone and won't change.

share|improve this answer

Give them the autonomy to choose what they think is the right technology stack.

Give them each a really nice 30" monitor and at least one other decent sized monitor. I used to laugh at the whole large monitor thing until I actually got one. Wow, what a difference it makes! It's so much better than two or three more modest displays IMO. Give them decent computers, keyboards and mice.

Give them any other software tools and libraries they ask for. Give them a dedicaded machine for builds and automated tests.

share|improve this answer
+1 for the monitor. Better yet have 2 big monitors. It's more ergonomic when you aren't constantly moving windows around. At my company every developer has 2 monitors. I can barely function with 1 monitor these days. – Lord Tydus Dec 13 '11 at 0:47

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.