Dave Donaldson

Decreasing Developer Ramp Up Time

Sunday, August 19 2007

At some point, every new software project must bring on additional developers in order to complete the amount of work being undertaken. The question that management always asks is, "How soon will they be productive?". Everyone (usually) understands that it's not realistic to expect a new person to be productive starting Day 1, but you know you can't wait a couple months for them to contribute either, especially for consulting gigs.

So the best thing you can do is to put things in place that significantly reduces the amount of time it takes for a new developer to be productive and add value to your team and the project. Below are things that I've learned to do over the last few years of leading development teams that helps new developers get up to speed as quickly as possible:

Explain the Problem
This should be obvious but is many times overlooked, especially for typical line of business apps. All of your new developers might be very sharp when it comes to .NET, but for them to truly contribute they need to fully appreciate the problem being solved. This means spending time with them in their first couple of days going over the issues from a *business* perspective.  It also implies making sure the developer understands the risks and impact if the project were to be delayed or if it were to fail (with whatever definition of failure is being used). The business problem is the reason the project exists, so make it clear.

Review Application Architecture and Design
Many times the overall architecture of an application is (mostly) in place by the time new developers are brought on board. If this is the case, you must spend time with them going over those things so that the new developers have a feel for where things are at, what should go where, and where to start looking when they first get into the codebase. Explain why certain decisions were made. Draw lots of pictures. Talk about things that still need worked on and things still undecided. And be sure to ask them for feedback (it's very important right from the beginning for new developers to know they have a voice that will be heard). Spending this time is critical because it allows you to make sure new developers are on the same page right from the beginning.  This conversation goes a long way in getting developers going in the right direction quickly.

Maintain a Wiki
I've found that having a wiki is a valuable tool in helping developers get up to speed quicker. It's a place to capture pretty much anything that comes to mind that new developers would need to know, such as:

• Tools being used to develop the project
  • With links to get them if they don't already have them
    
  • And with descriptions and info on how to configure them (for those that require it)
• Detailed description of the application architecture and design
• Coding standards
• Naming conventions
• Contact information
• Project-related documents
• And anything else that matters

And make sure to encourage the new developers to contribute to the wiki as well, especially with regards to things needed for the developer onboarding process. Afterall, being the newbies, they should have an idea as to things they would like to see as they come up to speed. So if they think something is missing, tell them to add it.

Provide Good Equipment
This cannot be underestimated, but unfortunately is on many occasions. There is nothing that saps developer productivity more than inferior equipment. Why give a new developer a hand-me-down machine with less than adequate hardware? This is very commonplace in the consulting world, where clients are increasingly forcing consultants to use equipment that they provide; meaning, developers can't use their own machines. And you know, I'm OK with that on one condition: don't give me or my developers junk machines I wouldn't let my mom and dad use to surf the web. And if you do, don't fight with me on requesting memory upgrades or additional hard drive space or a second monitor. Developers need the right tools to do the job, and having good hardware with which to develop on is part of the game.

Get the Latest Source Code and Run It
It is imperative that new developers should be able to connect to the source code repository, grab the latest version of source code, and run it as soon as they have the tools to do so (without any involvement from anyone else). This goes a long way in making new developers comfortable because they see a running application with functionality they can begin using. This starts to build confidence early in their ramp up period because they aren't spending a week just trying to get the app to build on their machine. Of course, this implies your builds are up-to-date and working, which, if you're running your development effort in a Continuous Integration fashion, should never be a problem.

Run the Tests
Assuming you have tests for your app (and you better), have the new developers run them. This is very useful because it gives new developers a sense of the testing involved for the application. It would be nice (at least for me) if all your new developers are well-versed in unit testing and TDD, but if they aren't, running the tests allows them to get a feel for what types of tests are required and how to write them.

Pair Up
Once you feel new developers are at a point to begin working on the app (for example, a use case), pair them up with another developer that's been on the team for awhile. That doesn't necessarily mean pair programming, but it certainly could. In any case, taking this approach provides yet another level of comfort for new developers before they begin working completely on their own. They should know that making mistakes is OK because the other person has their back and can guide them through it.

Post your comment

Name

Mail

Website