The Dangers of Using Inexperienced Developers
In this blog entry, I'll adress an issue that I've seen ruin projects, and cost other projects a fortune. And that's using inexperienced developers without proper supervision. It's more common than you might believer and it was extremely common during the dot com boom. That's one of the reasons so many of the projects during that period failed so miserably. And of course, most of their business plans were really bad - that didn't exactly help.
Avoid Junior/Inexperienced Consultants
If you're using consultants for a project, specifically request that the resources you get have at least five years experience as professional developers. Not necessarily five years as consultants and not necessarily five years using the tool you're going to use, but a minimum of five years working as developers - professionally.
Experience In Coding Means More Than Experience In Language X
Development experience is easily applicable to other languages/databases than the one you gained the experience on. The lack of experience is a far bigger problem.
For instance, if for a C# project you have the choice between an experienced developer with say seven years of coding in PHP, or a novice with one year of coding C#, the experienced programmer will in all likelyhood be more productive and create higher quality code than the novice - even though the novice had more experience in the language of choice!
Programming languages are not interchangable, but nor are they like learning new speaking languages. Picking up a new language typically takes a few weeks before you're productive and a bit more before you're fluent.
Experience Typically Means Productivity
When an experienced developer faces a problem, chances are he's solved that particular problem before -often times more than once. He's got a toolbox of solutions he can apply. If it's a truly unique problem in his experience, he'll know where to google for applicable solutions. His main concern is going to be how to solve it in a manner that suits the rest of the system, and how to solve it in a manner that's maintainable.
When and inexperienced developer is faced with a problem, his main concern is going to be figuring out how to solve it at all. Maintainability and integration with the existing system isn't typically even going to be a priority.
I'd claim that an experienced developer will be several times more productive than an inexperienced developer. Even worse, an inexperienced and clumsy developer can cause more damage than they do good, leaving others with a lot of cleaning up work to perform. Thus, a developer can become a resource drain!
We've got five years, my brain hurts a lot (/D. Bowie)
Don't count time in school as time professionally coding. Don't count time hobby-coding as professional coding. I'm talking about five years of day to day work of professional code or database development. It takes time and practice to produce high quality code. And low quality code is a bitch to clean up, you often have to toss it all out and start from scratch.
Some people will learn faster than others, so some developers will be really bad even after a decade, and some will be really good after a year or two (especially with the right guidance). But as a rule, experience is better than the lack thereof.
Some issues you'll contend with your go with inexperience are;
Bugs
It's hard to write bug-free code and that's ok - if you catch and correct the bugs! Testing code is also very hard, inexperienced programmers are not only more likely to create bugs, they're also more likely to let them slip through unnoticed.
Test every code path, consider every consequence, predict issues with interconnected systems - that's an art!
Poor Maintainability / Bad Code
Inexperienced coders typically write ineligant code that's badly partitioned and just badly built. They commit sins like copy and pasting large code blocks, which means that a bug might get copied to several locations. Fixing it in one place doens't mean it's fixed everywhere. It's just a mess and it's frustrating for everyone else in the project
I'd like to get back to a discussion about Bad vs Good code in a later blog entry.
Poor Documentation
Well, you'll have this problem with most any developer irregardless of experience level, unless you hound them about it. I'll get back to this entry in a leter blog entry as well.
Poor Adherence to Coding Conventions
If you've established a coding convention - a description of what code should look like in your project, an inexperienced developer is less likely to follow the conventions. Most juniors don't have the "capacity" to both figure out how to solve the issues they're faced with and to code it in a proper conventions-compliant manner. It's like learning to skate, you don't look graceful in the beginning because you're fully focused on not falling on your ass.
Also, newbies rarely "get" why certain things are important. And if they're arrogant (hey, it's been known to happen that every once in a while, an arrogant developer comes around - I know I was when I thought I was the hottest developer around), they'll even ignore good advice.
I've seen more than my fair share of inexperienced developers who even ignore proper indentation. That's like ignoring punctuation and capitalization in written text. It's near trivial to do right, and it lends a amazing increase in readability to the code/text. If a developer tells you it takes longer to indent properly, tell him I said that he's lying!
Resement Internally and Externally
Your team will be resentful that an inexperienced developer is causing issues for them to clean up, and your users will be resentful with you, the team and the project because of the number of bugs that slip through.
But If We Have To?
If no experienced developers are available, there are things you can do to minimize the risks;
Use Mentors
Each inexperienced developer should be assigned to a mentor. The mentor should be responsible for the code that the junior developer produces. If the quality is bad, then the senior developer is expected to notice and take apropriate actions (obviously not fixing the problems, but acting as a mentor).
At a minimum, the mentor should perform frequent and mandatory code-reviews, these should be reported to the project manager, so the project manager gets a feel for how the inexperienced developer is working out in the project.
You should make sure that the mentor is mentoring to your satisfaction, if the code stinks, take apropriate actions!
Balance Your Experience Level
You should balance every one or two junior developer with a senior developer, acting as a safeguard that the quality is kept up.
Pay Less
You can expect them to produce less, so why should you pay the same as you would for an experienced developer? Also, since you will have assigned a mentor, the time the mentor spends with the consultant is a cost to you. It's a cost well spent, but it's spent traing someone elses staff. The consultant might be gone from your project once he's experienced enough.
Y2k Bug in September 1999
In one project I worked on, one junior developer created a brand new Y2k bug in september 1999! That ought to be a record or something!
There was no review and no mentors, so he went unchecked. I accept some responsibility here, because I didn't do enough to correct the issue. The times when the more experienced developers tried to correct him, he was less than humble about critizism. That's a very bad sign i anyone.
Anyway, things steadily got worse and the customer started to notice. At one time I was called over by a user at the clients who had an issue. I refered the user to the junior developer who was responsible for that part of the system. At that point the user said "Oh, him? Well, never mind then." and she let the issue go unreported (though I obviously brought the issue forward).
Being inexperienced wasn't his only problem, lack of communications skills and a bit of arrogans didn't help.
In the end, the developer was let go, but by then a lot of damage had been done, both to the code and to the relationship with the customer.
So, How do New Developers Get Created?
Now you may be thinking "but if no-one hires inexperienced developers, how will any developers ever get experienced?", well if you're hiring developers for permanent positions, then I wouldn't recommend against hiring greenhorns. With permanent position, it may even be to your advantage to "mold" the developer to fit your organization.
However, make sure that you assign a mentor, as described above. If you don't have any developers in your organization, starting out with an inexperienced developer is probably a very bad idea.
9/19/2006 2:29:25 PM (W. Europe Standard Time, UTC+01:00) 
coding | development | consulting | developers