Seasoning the Raw through Extreme Programming

5 06 2007

One of the biggest issues facing IT companies in India today is hiring good staff. I think it’s become abundantly clear to my regular readers that this has become something of an obsession in my work. So, to break the monotony of dealing with idiots who claimed they were experienced, I started an experiment a month back with a couple of raw recruits straight out of college. Now these boys were sharp guys who had a good attitude to learn, and plus some basic knowledge, albeit quite limited and convoluted.

I’ve concluded that the primary drawback of hiring people “fresh” out of college is that they don’t know anything practical. The sad part is that their heads are so full of theory that by the time they get out into the real world, they’re completely confused and absolutely incapable of practical programming. I’ve mentioned this before in my earlier posts on the state of freshers in India.

In this case, I initially gave each of my two freshers some very simple tasks, different tasks mind you, that would require them to learn the basics of .NET programming. But after 10 days, they had made very little progress and I was left tearing my hair out and sitting with them for 3 or 4 hours just trying to explain how to use classes, how file reader operations work, etc. I mean this was baby stuff they’re supposed to have learned in college. And people wonder why I’m greying prematurely.

The trouble was that I really couldn’t devote this much time to these boys on consistent basis, and the company wasn’t big enough to justify a formal training program like what the big boys at Infosys and all do. At the same time, I was sure that just throwing them in front of a computer with some books and saying, “Code!” wouldn’t work fast enough. So, I hit upon an idea. What if I instead of using them as two separate programmers, I made them work as a single unit?

I got this idea from an article I’d read a few years back on how HP was using Extreme Programming to improve its coding standards. You can read up on Extreme Programming here @ Wiki. One of the concepts that I recalled from this particular article was that instead of have two programmers work separately on different tasks, HP assigned two programmers to a single workstation to work on a single task together. The idea was that the number of bugs in the code went down because there was a second person to verify the code as it was written. So while it didn’t actually speed up the development phase, it did reduce the time taken for the testing phase, an added bonus being that it reflected a higher standard of programming quality.

So getting back to my problem, I realized that the issue I was facing was that on their own these freshers didn’t have enough know-how to accomplish the task, but each of these guys had some knowledge that the other didn’t have. So, I made them work as a team, or one logical programmer to use geek speak, to accomplish a single task together at a single workstation.

I’m happy to say that this experiment was succesful. They delivered their new task inside of 3 days [the new task being one of equal complexity to previously assigned tasks]. I then had them work under a project leader to develop an in-house project for me. Not that I desperately needed the application, but it was a challenging project that required my freshers to cover all the basic concepts you need for a real-world .NET web application. 2 weeks in and they’re almost done.

What I learned from this exercise was that having a second person working on the same problem helped the freshers to think a problem through before implementing a solution, rather than operating on a trial-and-error basis. Additionally, the second “brain” helped to fill in gaps of knowledge that were lacking in the other person. So, together they would discuss a strategy, pointing out flaws in each others theory, and then implement that strategy together, testing and debugging it together. At the end of the day, they accomplished far more simply because they had more knowledge at their disposal, plus the ability to think things through before coding.

I’m not saying they’re perfect though. There’s still a lot of things they need to learn before they can become independent programmers. One major issue I’ve encountered, and one that I haven’t fixed yet, is getting them to conceptualize concepts and problems. For some reason, whenever I asked them something a little abstract like how does a web application work according to the client-server model, or how is a file uploaded handled, or how do URLs work, I encountered a major mental block. I’m only after the theoretical concepts, but for some reason since it’s applied theory, rather than definitions, they have trouble wrapping their brains around these ideas.

In the end, I realize that how to use these boys is not to talk to them about solving problems, but to clearly define the tasks to be delivered and them instruct them to do it. It requires a hands-on presence in the form of a team lead or project manager to clearly define for the boys what needs to be done, but once they’re clear on whats expected of them, they are able to deliver as per schedule. Based on the current results, I’ve decided to keep them together for another 3 or 4 months for them to gain more exposure before splitting them up.

The primary benefits of this approach are that a company does not need to invest in a formalized training program to train “freshers”, and that at the same time these freshers get exposed to real world programming from day one. They understand how live projects are dealt with, what methodologies are in place, what problems they are likely to face, etc. Most importantly, they learn the skills that are needed for them to become productive programmers quickly, especially those needed for the company’s ongoing projects. The company also benefits as it’s no longer dependent on hiring “experienced candidates” [refer to some of my other posts for my take on these clowns], and is able to groom and shape a team for the future.

So, in the near future, I can transition these two freshers into productive programmers who are capable of completing tasks alloted to them. True, they might not be ready to tackle problem solving and such, but that only comes with experience. But, rather than have non-productive people for 4-6 months, I have productive programmers within 3 months. And at a fraction of the cost of the “experienced programmers”.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: