4

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?

1
  • 4
    "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, 2011 at 0:45

2 Answers 2

3

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.

1

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.

1
  • +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, 2011 at 0:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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