When is a year of experience not a year of experience? When that experience doesn’t match your needs. Assembling the right mix of people for your software team can have a tremendous impact on productivity and quality. Find out how to discern whether a potential candidate will make the grade.
When is a year of experience not a year of experience? When that experience doesn't match your needs. Take my friend Zack, for instance. A VP of Development, he recently came to me with a problem.
"We hire the best people money can buy," he said. "They have degrees and tons of experience. Why can't we finish our projects on time?"
Zack wants his organization to crank out four to six releases per year. So far this year, they've released two—both of them were late. "Something has to change. Maybe it's my management. Maybe I expect too much."
"Maybe it's who you’re hiring," I suggested.
"They are smart people. They should be able to perform well."
"Perhaps you aren’t hiring people with the experience and skills you really need. Let's look at that. Can you think of any delays you’ve had that you can attribute to lack of skill?"
Zack considered that for a moment. “Well, there's Mike. I hired him a few months ago. He has five years of experience in developing: low- and mid-level design, coding, fixing. So silly me, I figure he knows what he's doing! But I was wrong. Someone with his experience should know that you hard-code as little as possible in a function. And, if you’re developing several similar functions, you group the common pieces into subroutines or classes, depending on your language. Right?"
"Sure," I replied.
"Well, Mike was implementing several serial drivers and forgot to add a key piece of functionality into the first driver. The tester reported the problem to Mike. When the tester received the next build, he first checked the original serial driver for the problem, and it was fixed. But when he checked the next driver for the same problem—sure enough, the original problem was still in the second driver."
"That will certainly cut down on your productivity."
"You betcha! Oh, and then there's Minerva. I hired her four months ago. She's a tester with over ten years of experience. Great hire, right? But listen to this. Minerva thought the only technique to test a simple user interface was to walk through the entire GUI, singly changing each parameter. It took thirty staff-hours to test her product's GUI that way. So Maxine, who sits in that cube over there and only has three years of experience, mind you, had to show her how to speed things up. See, Maxine had read about two-way combination testing—you know, the test reduction technique that would reduce the total number of necessary tests to a fraction of the original number." "Zack, it sounds like both Mike and Minerva were missing some functional skills that your project required, even with all of their years of experience. There are questions you can ask to help you find that out before you hire them. You have to probe for specific skills you feel are important. We can work on that. Who else do you have?"
Zack was on a roll now. "And then there's Mackenzie, a project manager with six years of experience. He transferred in from another division. In his last position, he successfully managed five small projects using a spiral lifecycle. I assigned him to manage a staged-delivery lifecycle project with more people and a longer total project time.
"During the initial project planning, Mackenzie tried to organize the schedule so that the project team could modify the entire product. What he should have done was take enough time at the beginning to define enough architecture and interfaces to allow several sub-project teams to work in parallel. One of the developers had to