I have been in several software projects but not as a leader. In all the projects we all knew the tools and languages etc. before the project started.

I am wondering if it is ok or is it a good practice to have a time for developers to familiarize themselves with tools and technologies after project kicks off (eg. After requirements specification)?

migrated from stackoverflow.com Apr 3 '11 at 11:33

This question came from our site for professional and enthusiast programmers.

  • Whether or not it's okay, it's necessary. How are you going to write it if you don't understand the tools? – Alex Feinman Apr 5 '11 at 14:39

If the familiarization is done in a comprehensive, requirements-driven manner, it's OK. Otherwise it's just another word for slacking, and you'd better start coding in an unfamiliar technology right away, and refactor later.

A good example of familiarization is creating a mockup of the system that uses the same key technologies and deploys to the same foundation as the target project. As steve314 adds in his comment, you'll make all the newbie mistakes you would have made if you started coding the project outright, but you won't have to throw away a lot of code that took the time to be written but made you learn nothing useful.

  • 2
    +1 - The best way to learn something is to use it. It's a good idea to do some familiarization exercises that cover the same ground that you'll use for real, in part because you don't mind making all the newbie mistakes in the learning exercises, but for most things you should quickly (often as little as a few days, or even a few hours) reach the point where the most appropriate learning exercise is to do the job. "Plan to throw one away" may still be good advice, though - hopefully for a few early components rather than the whole project, but that depends how novel the technology is. – Steve314 Apr 3 '11 at 12:06
  • I think that reading a tutorial beforehand is not "slacking". I learn best by reading documentation first. I am one of those kids who got a new toy and actually read the directions before playing with it. I usually had a lot more fun with it too, because I knew things that were non-discoverable otherwise. – Nemi Apr 5 '11 at 13:09
  • I agree that creating a mockup of the system using the same technologies as the target project is the best way to familiarize yourself with the tools. – Amy Patterson Apr 5 '11 at 14:40

If you have decided to use technology with which your developers are unfamiliar, it is ok, good practice and inevitable.


I would plan for some slower performance at the beginning of the project. There may also be some setup time. Try to get the setup standardized.

If you need significant familiarization, then you may need some training time. Well done training should be more efficient than just playing around with the tools. Self-paced training is fine, and may be more efficient. Get some cheat-sheets, or develop project specific cheat-sheets.

EDIT: Project specific cheet-sheets can be of three varieties (or a combination there-of).

  • Abbreviated cheat-sheets for tools used by the project omitting features not used by the project.
  • Cheat-sheets for project specific tools and or libraries. Basically, anything project specific that could be on a cheat-sheet.
  • Merged cheat-sheets for particular work-flows using multiple tools.

Automate your processes when you can. The cheat-sheet would then point to the appropriate automated process.

Consider using a Wiki to hold your cheat-sheets. This is also a good place to document your process. (It helps to document alternatives looked at and why the chosen one was selected.)

  • By cheat-sheets do you mean cheat sheets of tools you'll be using? What is project specific cheat-sheets? – serengeti12 Apr 5 '11 at 10:49
  • @serengeti12: Yes I do mean cheat sheets for tools you will be using. – BillThor Apr 5 '11 at 12:54

One thing I would recommend is taking some time to get a broad overview of what's covered in the framework and what isn't and also read up on best practices and common conventions of the frameworks/tools.

I've started some projects at a high speed where there wasn't time taken to learn in general about the frameworks and tools and we just learned as we went. This means though that often you only learn about the framework parts or tool abilities that you're working with directly, which can lead to the following problems:

1) reinventing something that your framework/tool already provides support for, because you didn't know it was there.

2) not following the correct conventions and best practices recommended for a tool, which can lead to maintainability problems down the line, problems upgrading etc.


On my projects we usually have a trailblazer when we are using new tools/technology/processes. It could be the same person or different for each task, but it needs to be someone who knows when they've been able to achieve the end-goal when they get there. The trailblazer gets to make all the mistakes and settle upon the way the project will do things. They then do some sort of presentation/how to guide/template/example that the other developers can then use and hopefully prevent all the other developers from making the same or other mistakes.

Other than that, I'm not sure specifically setting aside time to learn tools is a good idea. I would just leave that up to the developers to determine when they need the Just-In-Time training to take it upon themselves at that point. If you set aside the time and the particular developer isn't ready to use the tool yet, then odds are they will divert their attention someplace else. Then when they need the tool, that's when they'll learn it. In that event, I think you lost time instead of gaining time.


I would use a proof of concept stage in the project for getting familiar with new technologies and ensuring that they will be approriate for the job

  • Sorry,Is that a stage in the SDLC? How would you do that for example – serengeti12 Apr 5 '11 at 11:03
  • Yes. You would normally perform it before the design phase. In essence it is used to prove that you are capable of building what has been proposed. You could test out a number of different technologies to see which one(s) are appropriate for the job. If you haven't done the design yet you could maybe squeeze it in but it needs to be relavant to the project, not just playing around with technology for the sake of it. – John Shaft Apr 5 '11 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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