Motivating Your Co-Developers? 543
"Deadlines are super-tight (what else is new)... but all 'my' parts are ready on time, and I enjoy what I'm doing. After about a month of design and two weeks of coding, I've got about 50% of my software features. The others definitely do understand the requirements and the design, because we had plenty of discussions. 'All right, lets get what you've got so far, we'll just try the interfaces, even if your code doesn't do anything much yet.' 'I haven't tried to compile it yet.' Then I looked at the little code they've produced, and it's a disaster (abhorent coding style, serious logical mistakes, etc). Obviously, these guys understand the 'domain' problem (I would think that's the hard part), but suck at coding (which is apparently the really hard part for them).
Hiring new people this late in the project won't work, as anyone who has read 'The Mythical Man Month' knows. On this project, I have a de-facto role of a software team leader. Before, I've always been just a coder, not responsible for others. So okay, I'm doing fine with my part of coding, but that's no use. If others don't catch up quickly, we'll have serious problems delivering on time. I need to stop hacking on 'my' part of code, and help elsewhere. They definitely do understand the requirements and the design, because we had plenty of discussions. 'All right, lets get what you've got so far, we'll just try the interfaces, even if your code doesn't do anything much yet.' 'I haven't tried to compile it yet.' Then I looked at the little code they've produced, and it's a disaster (abhorent coding style, serious logical mistakes, etc). Obviously, these guys understand the 'domain' problem (I would think that's the hard part), but suck at coding (which is apparently the really hard part for them).
Obviously, I need to look into some way of helping or motivating, but without putting them off. I could just take over someone else's module and code it in no time. But if anyone did that to me... well that's out of the question."
How to motivate your codevelopers: (Score:5, Funny)
-JT
Re:How to motivate your codevelopers: (Score:2, Funny)
Re:How to motivate your codevelopers: (Score:4, Funny)
Use slashdot to your advantage... (Score:5, Funny)
Block "http://www.slashdot.org" at the firewall :)
Personally, I just complain about my co-workers on the front page of Slashdot... they all get pissed and quit, and then I can replace them with new people who know what they're doing. Seems to work....
Re:How to motivate your codevelopers: (Score:3, Funny)
The perfect motivator (Score:2, Troll)
Re:The perfect motivator (Score:2, Funny)
Re:The perfect motivator (Score:3, Funny)
Use XP (Score:2, Insightful)
Re:Use XP (Score:4, Interesting)
The whole concept of XP is a bit awkward and works best in either a teacher/student model, or using expert programmers who know eachother well. Nowhere close to panacea.
Not to mention the acronym sounds evil and M$-ish
Re:Use XP (Score:3, Insightful)
Try the pair programming for a trial period (maybe just a week). With a better idea of where the other programmers stand, the poster will be in a better situation to know what the long-term solution is:
Writing Code isn't the big deal (Score:4, Insightful)
Because MOST of the time of a project is dedicated to Maintainence and Debugging. Writing the code is the smallest part. As long as your team UNDERSTANDS the code written, you should be better off during the debugging phase. Just say "Hey I spent all my effort writing it, you guys need to debug more than me to balance it out!"
Bad programmers don't change. (Score:5, Insightful)
Re:Bad programmers don't change. (Score:4, Insightful)
The reality is that people are motivated by varying things (and "fear of being fired" is the #1 worst motivator and is the cyclical spiral to oblivion for any organization), and a good project manager understands how to understand and utilize those motivations (and it very seldomly is $, by the way): The biggest ___KILLER___ to motivation (and it's a killer in the sense that people will write garbage code, if any at all, regardless of their skillz) is a project death march: A project that has no hope in hell of ever being finished, and is absolutely guaranteed to be killed. Any talented coder will have a brain gnawing at them screaming "THIS IS A WASTE OF TIME!", and the truth of the mater is that in the end, sitting around reading Slashdot all day, or dutifully spitting out lines of code, has the same net result: The project is canned and the code is deleted. There are many projects out there like this, pursued by managers with agendas and severe myopia: If your project is like this then good for you, but realize that it won't be long before you too spend your days wishing for 5pm to hit.
Re:Bad programmers don't change. (Score:5, Insightful)
The original poster's commentary indicates that it's a relatively young/naive developer who is either a natural coder or a steady Eddie with an overblown ego doing the writing. Either way, I am guessing that he is quick to grasp concepts and ideas, and gets easily frustrated with people who don't -- and it shows. Even if such people try to be understanding or are "open" to questions, the way they phrase their answers is often intimidating to their peers.
You need to make sure people understand the project is truly a team effort, not a blame game, and encourage questions. If no one is asking questions, check with them daily to see how they are doing, but handle it as an offer to help out or clarify specs rather than just getting their status.
Learn the skills of your people. Those who can't code are often good at other things -- debugging, screen layouts, build management, etc. Very few people are actually useless, they just aren't necessarily good at what has been assigned.
When working with a team of juniors, start out by creating the outline of the code -- makefiles, interface headers, and stub code. Don't get into the details of your code -- make sure the overall project has been outlined. It helps juniors a lot to have a solid interface they are expected to implement, and it helps to modularize the system code.
When people ask questions, don't give them the answer, even if you know. I'm serious! Guide them with questions that lead to the answer, but let them come up with the solution if at all possible. This helps them to learn how to think (your questions show what they should be asking and thinking about), and they gain confidence by coming up with solutions "by themselves."
Ignore all the postings you've seen about beer, pizza parties, and threats of layoff or termination. You'll never succeed with a project if you are wasting your time and budget on frills and turning your staff into nervous wrecks.
If you do encounter a truly useless clueless "developer" who just doesn't "get it", make sure they're working on something non-critical and that their access is restricted. If you have to keep them on the project, try to use them as testers or for "grunt work" like build management. Even the most clueless person can follow a checklist to test software or compile code, and sometimes they can actually become quite good at it. Believe it or not, you need people who will be happy doing the mindless work -- most of the work on a large project is mindless.
Don't create your schedule on the assumption that everyone is going to code as fast as you. Be realistic, and then double the time allotted. Sad to say, I've often found that still doesn't allow enough time for some people.
If you find anyone on the team playing the blame game, snuff that thread. If someone complains about weak specs, redirect the discussion to suggestions about how to improve the specs. If someone is blaming other people for being late with interfaces they "need", redirect to a discussion of modular programming and how the interfaces can be designed without a full implementation. Whatever you do, don't let people get away with blaming others for their own shortcomings.
Perhaps most important, don't use the "big stick" of layoffs and termination to encourage people to work. If they are any good, you'll just scare them into finding another project, leaving you without resources. If they really are useless, no threats will improve their skills and you're going to turn the team into quivering, terrified blobs who would rather chew their own arms off than ask you for help or guidance.
Failing all of the above, make sure that management is aware of delivery issues and potential schedule changes early on. Even if you think you can recover lost time, make sure management knows the time has been lost so that it isn't a surprise if things don't turn out as you hope. Ensure that you've got a feature prioritization so that you know which features to sacrifice if it's critical to get "something" out for a given date.
Finally, keep smiling and keep it light. When all is said and done, it's just another project, not your life, and you'll only get ulcers by stressing excessively. More often than not things don't work out as you'd like, so learn how to manage them in the direction you need when they take a turn.
Being an arrogant SOB myself, it took me years to learn to be more gentle with my coworkers. Rather than bluntly stating my disappointments, I find it's much better to provide them with the interface headers (potentially with stubs), and let them code from there.
Re:Bad programmers don't change. (Score:5, Insightful)
Re:Bad programmers don't change. (Score:3, Funny)
You've got it made. Management will surely know that you've been doing all the work - because right now you're working with your future management team. So try not to piss them off too much !
The Earth is truly flat - it's only space that's curved
Don't motivate... (Score:2, Insightful)
There are other developers out there. Some of them actually produce code.
Re:Don't motivate... (Score:3, Insightful)
If you have sufficient weight in the group, then, you need to take over the project, fire the other developers, and start interviewing.
There may be an option...
You do all or most of the thinking, they do all the monkey work. First-year comp-sci stuff... build them up slowly when they show insight or improvement. If they can do some of the assembly parts (IMO also monkey work) then have them do that.
If they understand the project domain then make them write the test cases. Have them write the test divers. It's obvious these people need daily supervision, chat with them about what problems & challenges they're having on a daily basis. Review each other's code. Peer review is a great educational process.
How's this? Fire the one that sucks the most. If you can hire a (one) ringer. If that doesn't work out or you can't find a really good programmer don't hire. If the other team members continue to not work out then let the others go and report that your project will be done by you... then ask for stock (or options) and early completion bonuses.
Re:Don't motivate... (Score:4, Funny)
1st place is a new Cadillac
2nd place is a set of steak knives
3rd place is "you're fired"...
It's worked before...
q:]
MadCow.
Well.... (Score:3, Insightful)
Re:Don't motivate... (Score:5, Funny)
Allow me to introduce you to the term "At Will" employment. That means that one is employed at the will of the employer. If the employer loses the wiil to employ someone, they can be let go with no reason whatsoever.
HOWEVER...
Thia only applies if one is male, white, under 40, has no disabilities that fall under the scope of the ADA, and (in some states) straight. If you are not one of these, you fall into a "protected class" and, although one can still be fired, the employer needs to document it REALLY well.
Re:Don't motivate... (Score:3, Insightful)
This firing only applies if one is male, white, under 40, has no disabilities that fall under the scope of the ADA, and (in some states) straight. If you are not one of these, you fall into a "protected class" and, although one can still be fired, the employer needs to document it REALLY well.
It's kind of ironic that due to discrimination laws, for the first time in history, young white males actually are superior to all other groups in one way: they can be easily fired.
Don't be an ass. (Score:5, Interesting)
If you truly want to bring the "lesser" coders up to speed, you're going to have to make an investment of time. You may even want to consider pair programming for a period of time. Not only will it make the other coders familiar with your style, but it may make them aware of many "tricks" that aren't documented in your standard learn-to-program-in-21-days piece of garbage college course.
Typical geek responses (Score:5, Insightful)
Did y'all even read the whole original story? This guy has a problem that he needs to fix right now . Firing people for two weeks of uselessness isn't going to solve the problem. If you haven't read The Mythical Man Month, go read it now. Bringing on new programmers half way through a job often makes the job take longer. Firing the old, less effective folks, and bringing on new folks is going to do just that. At the very least, the programmers that are there know the company and know what the project is and know all the other people on the project.
The original poster did not ask "what should I do?", he asked "how do I make these people more effective?". Hiring replacements can sometimes take months, and when you do so, you're not guaranteed that the new programmers are going to be any different than the folks you just fired. So let us focus on how to solve the problem, not make it worse.
Fire them. Now (Score:3, Insightful)
I had exactly this situation myself - I had a programmer who was totally incompetent. Unfortunately, his job title put him squarely in my critical path. I had MANY discussions with management about this, and every time it boiled down to "well, something is better than nothing, isn't it?"
Wrong.
We downsized, and he went. Now, I have a competent person filling the role. Guess what? We are having to rip out all the code the moron did, and re-write it. Because we were paying the moron's salary, we couldn't hire a good programmer to replace him. Because we wouldn't admit he wasn't up to snuff, we didn't schedule correctly. Because he didn't identify flaws in purchased code, now we have to live with them, because the service contract has lapsed.
Joshamania is correct in that firing these people will slip your schedule, and that hiring new guys will slip your schedule. However, your schedule is going to slip, period - take a deep breath and get over it now. You can take a single slippage, or you can continue to hemmorage time through these bleeding assholes (now there's a vivid image, if I do say so myself!).
Suck it up, fire the guys who cannot/will not get the job done, and get people who can. You cannot afford to pay someone who isn't pulling their weight.
*Why* aren't they coding? Good/bad? (Score:5, Insightful)
You need to understand why they're not coding. Here are some possible reasons:
- They're still trying to clarify the requirements. Some projects have well-defined requirements, but many real ones don't, and maybe their parts are fuzzier than yours, or maybe they need help understanding them.
- They're still designing interfaces and test plans, and are wisely not writing code until they know what it should do and how to do it right. Maybe your part has more obvious interfaces than theirs, or maybe they need some help defining them, or maybe you're rushing off writing code before you've done your critical design work. Writing code is only the middlish 10% of the job.
- Maybe they're trying to build tools they need to build their real code. This could be forward-thinking planning, or it could be they don't realize the resources they've got available and need help finding / getting them.
- Maybe they're underskilled and over their heads and don't know how to do the job - but apparently you haven't been communicating with them, and also apparently they haven't been communicating with you.
So talk with them first and find out what's going on. If you can't come to an understanding, find a manager to help -- I don't mean a Boss to tell them what to do, I mean a Manager to actually manage the project and people. You probably need one of those anyway, and sometimes programmers can do that but sometimes they don't have the people skills to do it.Re:Don't be an ass. (Score:5, Informative)
Pair programming will probably make them stay on task better, since they'll sort of "guilt-trip" themselves into it. When one of them has a problem, chances are the other will know how to solve it.
Also institute daily builds using ant or somethign of that nature. That way there's no excuse for not having compiled the code--and when it doesn't compile, everyone gets a report. Another way to push the guilty parties a little harder to get their ass into gear.
I think most of the concepts of extreme programming apply to your situation. Programming methodologies in general hold back great programmers, but their reason for being is to help mediocre programmers become good (and productive) ones. I'd say this is a textbook case.
Also, having been both the 90%'er and the lazy fuckoff at various points in my career, i can tell you that motivation is everything. Pool tables and perks won't get the work out of them--they truly have to feel like a team, and feel like they're letting the team down when they slack. From your post, it would seem that you don't really feel the team effort either. I think that the most important change you can make would be to help foster that atmosphere. You also mentioned being the defacto lead on the project; don't assume that position unless its given to you by someone with authority to do so. It pisses off your coworkers.
Re:Don't be an ass. (Score:3, Interesting)
I wasn't specifically thinking of eXtreme programming, but pairing two of your lessers will certainly add motivation. It's much harder to play freecell if you have another person sitting there watching you be a dipshit.
Re:Don't be an ass. (Score:2, Insightful)
It's not who has the skills, the idea is to succeed. They win as a team and they fail as a team. Telling them that they need to get their skills up to par won't do much good. When I've run into this problem with people, I try to make them feel at ease. Try holding after hour gatherings the local bar. Then don't talk about work. Once they feel you're not an ass, then start bring up the concepts of work. When I've treated by co-developers with respect, I generally get respect back.
Re:Don't be an ass. (Score:3, Interesting)
Turns out he was just really good at getting hired and then talking others into doing the work for him.
Of course people like him ended up getting fired every 2-3 months and moving onto some other company to leech off of.
Fact of the matter is becasue of the boom, everybody and thier dog decided it would be a great idea to get into tech (coding, networking, whatever)
Companies were so starved for labor that they would hire anyone who even sounded like they knew what they were talking about.
now that we are bottoming out and IT budgets are getting slashed only the best techs and the best of the bullshitters will get through.
My advice: dont let these bullshitters continue on, send them packing and hopefully they won't sucker some other company (if they do hope its your competitor).
I would like to feel sorry for all the people who have been laid off and fired during these times but from what I've seen many of those (there are of course exceptions) who have were worthless anyway and the teams I'm beginning to see now are more focused, better trained, more expierenced and know what its like to deal with the real world.
Of course there are still many fakers out there and I only hope that we can weed even more out over time.
And before you go off ranting about people who are just starting to learn: I have no problem if you are new and just learning, what I have a problem with are those who know the buzzwords and can code some scripts then talk a big game. However when it comes down to the wire and you have to go live in 3 weeks and still have a week and a half of Q&A and you still havent learned the API of the application youve been coding for the last 6 months then I have a problem.
Do I sound bitter??
and yes my spieling and grammer sucks.
Re:Don't be an ass. (Score:3, Insightful)
Yep, that works great. Unfortunatly, after you have respect you still get to do all the work yourself. People who don't work will never work unless their job is on the line. People who can't figure out how to do their job after years will never figure it out. Unfortunatly a sizeable percentage of professional programmers fall into one of those two categories because the jobs paid well, and there weren't as many good programmers as there were jobs. It's also hard to tell if somebody is a good programmer or not when you hire them. You typically can't look at their previous work like you can with somebody from almost any other profession. Also, people who can't tell and hire bad programmers, tend to hire lots of bad programmers. Anyway, back to the point: Respectful coworkers are not necissarily competent, hard-working coworkers.
Of course for some of us that's not an issue, because the rest of the development staff on your project gets laid off and you have to write and test the whole 20k line product yourself anyway. I'm not bitter though. I didn't have to stay, and at least I like all the code now, and when something is broken I don't have to count on somebody else to fix it. Unfortunatly, the long hours aren't scoring big points with the S.O.
Not doing their jobs.... (Score:3, Insightful)
If you pay a carpenter to build you a table, come back when they say it'll be done, and they have nothing... are you still going to pay them?
It sounds to me like at least one firing is in order... if you're going to be past deadline, maybe you can make up for it by being under budget.
Doug
Re:Not doing their jobs.... (Score:3, Insightful)
That last sentance in the original question really sums it up. How do you deal with people when they either don't care or they don't take any pride in what they do. I see it all the time, and I don't have the power to just cut people off or fire them.
Unfortunately you just have to suck it up, act in a professional manner, and hope that our good deeds will speak for themselves one day. Of course, given the way things work you shouldn't be too surprised when that isn't the case. Sometimes life sucks but other times it's only moderately lousy...
frequent feedback and monitoring (Score:3, Insightful)
Re:frequent feedback and monitoring (Score:2, Interesting)
A big stick (Score:2)
Sure your'e not serious, but they don't know that.
A few suggestions... (Score:4, Insightful)
Here's your decision tree (Score:4, Insightful)
If this isn't feasible: Either your product is vital to your company's survival, or it isn't. If it is, then it is your responsibility to let your boss know about your project's troubles, and his boss, and keep going until you reach the CEO, if necessary. If this doesn't work, then the next thing I'd design, if I were you, would be my escape.
If your product is not vital to your company's survival, then either it will get done, slowly, and you'll have no life until you're done; or it will just fall apart.
Meetings (Score:4, Insightful)
Threaten Layoffs (Score:2)
M@
Move up the food chain (Score:3, Insightful)
Here's what I'd do (Score:3, Insightful)
you have to seriously assess whether the people you are involved with are competent. If you're absolutely stuck with them (assigned class group, nobody else available) then you have to do two things. These are to plan on doing all the work yourself and to come up with a new schedule based on you having to do the whole project. If they contribute anything, it's a bonus.
If you can get someone else who is competent, get them. Brooks was right but like most authors he is only 100% right when the situation exactly matches the one he experienced. If it just can't be done with only you then what choice do you have but to add someone else? I believe Brooks showed that you definitely experience gains when you go from one to two programmers, even from two to four. You just don't gain much at all when you go from one hundred to two hundred.
Whatever you do make it clear to your manager/professor that you did the whole damn thing. Make sure each module is owned by the person who actually completed it. And if every module has your name on it, perhaps you'll take some credit away from an otherwise bad situation and the others will be assigned tasks better suited to their abilities in future.
Re:Here's what I'd do (Score:3, Insightful)
If he's in charge, then maybe they're waiting for him to take charge.
Pair Programming... (Score:2, Redundant)
a real answer (Score:4, Informative)
I know from personal experience that this is a good motivator.
Re:a real answer (Score:2)
Its a tough job and a somewhat dangerous one.. (Score:5, Interesting)
(2) Sometimes its just easy to laterally move developers from one project to another if they are not being productive, than bringing the whole team and the motivation down. This could be done without raising any suspicions and with diplomacy.
(3) Sometimes constant probing helps, sometimes it doesnt. Reminds me of the dibert cartoon today where the guy wont do a thing without some sort of threat. He may not need to be threatened but send the PM to him every couple of hours anyway. Sometimes this could be detrimental to his position, but atleast he might realize somethings wrong.
(4) Theres shit happening everywhere and in every other company. This guy could just be freakin out about his job, his family, his wife, his parents and everyone he has to support if he loses his job. And hence instead of working hard to sustain his job, he might do the other, by wasting time getting more tense day by day. Its better to have the PMs or someone else from the team he confides in, to talk to him. But then again, that just might shoot his stress level through the roof.
(5) There are some people who just suck at certain stuff, it could be coding, communication or inability to gather requirements from the right people, and in turn building stuff that theres no need for. You will have to address these issues from the team leader level, keeping your team focussed towards the common goal
(6) These are people we are talking about here. Sometimes nothing works. Thats the way it is.
Re:Its a tough job and a somewhat dangerous one.. (Score:2, Insightful)
You can't say their code sucks..that's a negative comment. You have to tell them thr problem. For example. If you made a deadline for friday to have such and such modules completed (you DID make a deadline, didnt you?), and they havent done it, ask them why? Are they having trouble with something? Do they have all their tools? Do they need Schubert in the background? Shit, use the company account and buy them a book if need be. I've bought books out of my own pocket to help my coders. There has to be an open line of communication. What is the problem they are having? Are they Lazy? Well, you can't stop the laziness.Hire a consultant for 2 weeks if you have to. Get a telecommuter who will bang code at home..Give him a CVS account, review the code and see what he can do. As a manager/leader it is your responsibility to keep those lines of communication open. The belief that "if you want things done right, you have to do them yourself" is a TOUGH one to break. I used to do it..and you usually come off as an arrogant prick. If they feel you'll just do it ANYWAY, they won't bust their horns, you get me? Like when you were a kid. If you didnt want to do something, you did a lousy job at it, so your MOM owuld do it and she wouldnt ask you again....same principle really. You have to let them know that THEY are accountable for their own code..not you.
Pair Programming (Score:4, Informative)
See www.pairprogramming.com . If you haven't tried it (and many people haven't) your reaction will be "that would never work, and I'd hate doing it." The truth is that it works very, very well, and people like it when they try it.
By pairing with the newbies, you can mentor and monitor them Change pairs several time a day, insist that all code is written in pairs, and before long, you'll have a team of clueful people. Total team productivity will quickly rise.
As I said, if you haven't tried it, you're almost certainly going to think it's a bad idea; turns out it's not. Anyone tempted to follow up with "that would never work, PP sucks" please go off and try it for a week, first.
Re:Pair Programming (Score:5, Informative)
Customer Team Member - Teams have someone (or a group of people) representing the interests of the customer. They decide what is in the product and what is not in the product.
Planning Game - XP is an iterative development process. In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimating the feature costs. Customers select features and package the development of those features into small iterations (typically 2 weeks). Iterations are combined into meaningful end user releases.
User Story - A User Story represents a feature of the system. The customer writes the story on a note card. Stories are small. The estimate to complete a story is limited to no greater than what one person could complete within a single iteration.
Small Releases - Programmers build the system in small releases defined. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system.
Acceptance Testing - The customer writes acceptance tests. The tests demonstrate that the story is complete. The programmers and the customer automate acceptance tests. Programmers run the tests multiple times per day.
Open Workspace - To facilitate communications the team works in an open workspace with all the people and equipment easily accessible.
Test Driven Design - Programmers write software in very small verifiable steps. First, we write a small test. Then we write enough code to satisfy the test. Then another test is written, and so on.
Metaphor - The system metaphor provides an idea or a model for the system. It provides a context for naming things in the software, making the software communicate to the programmers.
Simple Design - The design in XP is kept as simple as possible for the current set of implemented stories. Programmers don't build frameworks and infrastructure for the features that might be coming.
Refactoring - As programmers add new features to the project, the design may start to get messy. If this continues, the design will deteriorate. Refactoring is the process of keeping the design clean incrementally.
Continuous Integration - Programmers integrate and test the software many times a day. Big code branches and merges are avoided.
Collective Ownership - The team owns the code. Programmer pairs modify any piece of code they need to. Extensive unit tests help protect the team from coding mistakes.
Coding Standards - The code needs to have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style.
Pair Programming - Two programmers collaborate to solve one problem. Programming is not a spectator sport.
Sustainable Pace -The team needs to stay fresh to effectively produce software. One way to make sure the team makes many mistakes is to have them work a lot of overtime.
Re:Pair Programming (Score:5, Insightful)
Well, no. That's not true at all. In fact, XP advocates universally recommend what Kent Beck attributes to Don Wells in the first XP book:
1. Pick your worst problem.
2. Solve it the XP way.
3. When it's no longer your worst problem, repeat.
You shouldn't and actually can't adopt XP all at once; you have to start somewhere. And for this guy, pairing is the place to start. You certainly can't recommend that these folks who can't squeeze out any code at all by themselves be encouraged to styart refactoring his code, can you?
Re:Pair Programming (Score:4, Insightful)
I agree! (Score:3, Insightful)
1. Be open to questions. This will help them respect you as a leader. Make it know to everyone that if they need help then they should ask and you won't bite their head off. You might have to restrict the time if the question asking gets out of hand. Maybe only allow questions before noon. Then you can get your own work done in the afternoon.
2. Spend time sitting down with each member of the group and code with them. Take turns writing the code. Again, do not bite heads off. Don't sit there and simply write their code for them. Explain the concepts that they are missing without belittling them. Have them pair up with each other as well. You will be amazed at what two idiots can teach each other.
3. Dr. Pepper. Lots of it.
4. Stress relief. Allow them to check /. once a day.
5. Have a weekly one hour class. Have someone teach it once a week on some aspect of their code or a programming concept that is useful in what you are doing.
I have seen people that I initially had very little confidence in become pretty proficient at doing their tasks. They didn't themselves in a vacuum, they trained (and motivated) each other.
Re:Pair Programming (Score:5, Insightful)
Same Situation (Score:2, Interesting)
My solution is fire him!
Fire them. (Score:5, Insightful)
It's not out of the question, it's the answer. Not doing the job you were hired for is a fireable offense.
Show them the coding standards that are to be followed. Show them the requirements. Show them the deliverable date. If they can't make those 3 things come together to the degree neccesary, show them the door.
age old question (Score:2)
now -- i would say first is to set intermediate goals (divide project into smaller portions) and get daily updates. spend 15 min every day and see if they ran into any trouble with today's work, etc etc. this way deadline is always 8 hours away, and there won't be any CS-101 "i will wait till the night before the project is due" symptoms
two -- get together with them and do some stuff -- be *friends* and THEN work-partners. an activity that requires no social interaction and gets a lot of bonding is 1) drinking. 2) drinking at a strip club. or golfing or whatever. when you guys are buddies, 1) they will feel at ease about seeking your help, and 2) they would hopefully get your vibe on the urgency of things. sidenote: be friendly but draw the line if people start to take advantage of this relationship
3) plan for the worst and be prepared for extreme measures. "kill a chicken to demonstrate to the monkeys" is a badly translated old chinese proverb. if it's necessary, fire somebody and be prepared to take up the slack. if everything else fails this should get people into a more productive mode.
well... that pretty much covers everything from holistic to draconian... so...
My advice (Score:2)
You should also set task deadlines and adopt a "no surprises" approach -- it's ok to change a deadline, but to do so they need to give you advanced warning of the obstacle and ask you for help up front. You should set the deadline based on how long you think it *should* take. Give them lots of feedback on how they are doing, which means not putting up with any crap. Challenge them.
Communicate to your boss that the others are struggling and that you are going to have to spend serious time mentoring. Managing up is very important, so spend a lot of time communicating to your boss on the tasks and progress of the others.
Too late (Score:2)
How to do project management is covered in many textbooks, but they'll all tell you to monitor what is going on, so you don't have a surprise on delivery date to discover that nothing has been produced, and take corrective action when you discover a problem.
In a competently managed project you simply can't arrive at the position you describe. Sure, you can get useless programmers, but you should have discovered this and dumped them months ago. (Or, if you personally don't have the power to dump them, you could have screamed enough at higher management that you don't even need to say "told you so".)
Your boss should recognize the efforts. (Score:3, Interesting)
Utilities and tools (Score:2, Interesting)
Mentoring... (Score:5, Insightful)
Most new programmers tend to come to me with nothing more than a vague sensation of "it doesn't do what I want it to." The proper reply for this is "come back to me with a good question." Until they can do that, they cannot be helped.
Once they have a good question, don't give them an answer; give them the other good questions that lead to / issue from that question.
Once someone knows how to ask good questions, they're halfway to becoming a good programmer.
Have a good talk to them. (Score:3, Insightful)
I wouldn't go gung ho on them but you have to get some clarity on why they didn't do their work and you have to draw a line somewhere. Just make it clear to them.
It's been said, but.. (Score:2, Insightful)
Do replace them.
Really, They are actually slowing *you* down. Motivate them into another job.
After that, hire a couple of proven contractors to catch it up. Contractors love short deadlines, and keep an eye out.
=== ANSWER #2 ===
You stupid bastard.
How long were they able to work without supervision? You are obviously not following any decent development methodology.
At this point, you need an XP [extremeprogramming.org] style devlopment process in place.
1. Put SHORT (1-2 week) iterations in place.
2. Get a commitment of features that they will deliver.
3. Have them code them
4. MAKE SURE THEY WORK IN PAIRS. Now ordinarily, I'm not a advocate of pair programming, but these people obviously need constant supervision.
5. Install Web-tracking software on their PCs and/or the firewall. They are obviously losing the time somewhere, and it's probably due to web browsing.
5.1 alternativly, put a corporate firewall in place, and use a proxy. block 100% of the sites, and have a policy/procedure for adding sites to the "do not block list" at the proxy. Do they need to check Ebay/Slashdot/cnn/hotmail/farmchicks.com ? during working hours. Hell no.
6.[back to coding...] If they fail to deliver the promised code in the first iteration. FIRE THEM. Useless twits make all software development staff look bad.
Motivation is the wrong approach to use at this point in time. They are being paid to do a job. Do not continue to pay them for non-performance.
*whew*
Re:It's been said, but.. (Score:5, Insightful)
I agree with some of your points, but I completely disagree with this one. From my POV, people have to be motivated somehow. Usually (or at least usually for me) it's because people have professional pride, somehow they feel what they do is important and/or interesting. Hopefully both.
If they go to Slashdot instead of getting something done, it's not because they can go to Slashdot (or if that really is the problem, they are weak spineless losers who should be fired right away). It's because they prefer that over working. Preventing them access there won't boost motivation or morale. You'll just be plucking small holes in the dam, to no end. On the other hand, if they do deliver and then browse weird web sites, who cares?
Programmers are not factory workers. They don't avoid doing job they like. But if they don't like their job (whatever the reason is -- from jerk boss to boring assignments to incompetent coworkers), they may well do something else. But this something else is usually "anything else", not just specific things you need to block.
In short, motivation is the key. Motivation, skills and experience -- threats can only gain minor temporary motivation ("I can't afford to lose this shitty job"), and never improve their skills (nor constitute useful experience).
Code reviews? (Score:2, Insightful)
Mod Parent Up... code reviews!!! (Score:2)
Code reviews can be very constructive. And even if they are "vicious" in terms of the minutiae they cover everyone learns. My favorite thing to do is to A) invite my office mate to my inspections- since he doesn't know any ADA he asks a WHOLE lot of questions- very good if you can answer them all, andif you can't, why not?
and now I invite B) the software architect. True he's a busy man but he goes through that code with a fine tooth comb!
In addition, frequent code reviews can also show what good code does look like. Start by reviewing YOUR code (the one that's 50% done). Then they have a model to work from.
Software Engineers don't code from scratch, they copy and modify!
Take Charge! (Score:2)
First, assess peoples skill and motivation levels. Senior, well-motivated people can be checked on every month or so. Less competent or motivated people may need to be checked on every day.
Give people as much respect as they deserve, but no more. If some people don't do a very good job, make sure that you have frequent code reviews. If they are unwilling to accept criticism from the more experienced people and do the job right, don't be afraid to yell. With an ideal team, motivation is not a problem. With problem cases, don't let it slide. Don't be afraid to point out to them that there are hundreds of more qualifed unemployed software people who would be happy to have their jobs.
Make sure that you have a good process in place. I don't mean anything bureaucratic, but make sure that you do design reviews and code reviews. Make them write something up. Get a definition of the api for the module. Review all code that is written. Require that a test plan, and possibly test code is developed. By implenting a system of reviews, mentoring can be done, and teamwork developed.
Lead by example (Score:2)
If you think there really is opportunity to effect change in people's coding practices, try to gently lead people in the right direction:
Have a code review--of *your* code. Be sure to accept a few suggestions even if they're a bit suboptimal. Reviewers will be exposed to better coding practices, and will be less hostile to suggestions about their own code.
Team up developers. I'm not talking about XP here, but how on earth did six weeks go by without you noticing a lack of code? Create two 2-person teams, pairing a code-skills person with a domain-skills person. On your team, spend more time exploring the domain space, and set small goals daily or at least 2 or 3 times a week. It's not micromanagement, its setting the tone for how to work. If you don't have a 2nd code-skills person, maybe you need a personnel change.
Managing isn't as much fun, but that's why you get the big bucks (right?)
Let your bosses motivate them. (Score:2)
As long as your bosses know that delays aren't your fault, then you can try to motivate them. The truth is, if they aren't doing their work probably nothing you can say or do will change that.
Managers? (Score:2)
Is this not why managers exist? They should be dividing tasks and setting dead lines for each of developer.
Come now, you really didn't think the typical manager spent the entire day struggling to create the perfect powerpoint presentation or flooding eachother with scathing emails now did you?
Scare them ;) (Score:2, Insightful)
1) Like I say scare them. You don't have to be really in their face "I'll kick you ass" sort of thing, although you could try that;). Emphasise(sp?) the importance of their component and the consequences of not producing. This should be used if their really lacking in motivation but should not be the 1st choice - how they take it will depend on the personality.
2 Preferred option) Get them started. We can all have difficulty starting a project, overcoming a mental inertia is an issue I have most times. Sit with them and start them off - outline a framework and expected milestones for their component. Once you see they should have started regularly review their progress. Not to regular to be intrusive or nagging but enough to know they are expected to produce a quantity of work in a given period (say a week or Wed and Fri?). If it doesn't work See option 1.
In fact sod it - rule with an iron fist muhahahahahahahahahaha....
.
I've had similar problems (Score:2, Insightful)
I knew it was time to cut bait when I was spending as much time dealing with his product as it would have taken me to do it myself.
If you are a project leader you must budget a big percentage of your time just to keep the rest of the team on track and on schedule. It's hard to do this when you could be pounding out code but it's absolutely necessary to keep the load balanced.
Be sure you have short term goals for each coder and review progress often. Let the coder set the goals and you can agree or encourage more work - usually their goals will be good enough.
Watch your time and dump anyone who takes a disproportionate amount of management time with no improvement in productivity.
Well... (Score:2)
A good lead developer keeps on top of their team. Review your team's work at least weekly, visit them for a quick chat once or twice a day, offer help/advice at every opportunity, and keep in close communication with the Project Manager/business end of things. The sad truth of the matter is that 20-50% of your time is going to be spent taking care of your team; get used to spending entire days without writing a single line of code on your own. If your developers are under-developed, you're doubly responsible for guiding them as best you can from the very beginning, or pressuring the PM to get them training at earliest convenience (and, in any case, keeping PM informed of the fact that the developers are really lagging and that the project is going to have trouble hitting deadline.)
As for the predicament you're in now, there's not much you can do besides busting your balls to help the developers (yeah, it'd be nice if they came to you, but it's the lead developer's job to go to them,) and talk to the PM about damage control. Look at what has happened, learn from what you can, and make sure not to repeat it on the next job.
Note to editors: Yeesh. This passed as front-page? This is barely readable, much less first-draft quality. Sure, it's an important issue and well worth posting, but at least clean the danged thing up, or send it back to the submitter to do so!
Find out what the issues are (Score:2, Informative)
Second, notify your management AND the project leader/sponser. The sooner they know about possible delay issues the easier it is to figure out how to correct the situation.
This is a hard question to answer. Is it motivation they need, or do they just not know what to do? If you are responsible for their contributions, you might be wary of contacting management before finding out what all of the issues are. If you aren't, then a mangement update is in order.
There are probably two reasons for their lack of completed work. 1) They are not doing their jobs, or 2) they do not know how to do their jobs (ie they do not understand how to work on a project, or they are not technically qualified. Either way, they should be removed to do something they are capable of doing).
Good luck.
Daily CVS Postings (Score:2)
Another way to do it is use a project tracking tool that has percentage completed goals in a nice display. IPM does this (Search Freshmeat for it) in a nice easy to see display. Shows a little graph of percent done per project and it allows multiple users.
Show them you are waiting for them. If 1 or 2 people are waiting for 3 more, the 3 should start feeling awkward. That and you have a conclusive tool to show the boss man that the rest of your team sucks. You can also post little notes, "Stuck? Ask someone for help." and such.
I got stuck with a developer who couldn't write one javascript function in 2 weeks. It was absurd, the boss didn't fire her because they both came from the same town in India and enjoyed to talk about life back home. We just cut her out of the loop. She received no projects. When my boss would ask me, I'd tell him she couldn't finish and to prove it would give her some minute task that wasn't important and after a couple weeks wouldn't have it finished. No biggie, don't rely and you don't get disappointed.
Questions and options (Score:2)
Different working styles (Score:5, Insightful)
The critical thing to manage different working styles is to clearly communicate your expectations. If your coders see a general project plan, they may well assume that the milestones you have set are "guidelines" and not requirements. If so, they will instead be aiming at whatever they consider to be the drop-dead milestones. But if you clearly get across that every milestone must be met then each person can manage his/her own working style appropriately... even if they may have to come to you and explain that the deadlines you have set will not work for them.
That is my 2 cents. It is also possible you just have an unmotivated, unskilled team and all of this "work style" stuff I am saying is irrelevant. But I find too many managers (both newbies and veterans) assume people are identical plug-in replacements which work the same way they do. Humans just don't work that way.
Find your (their) niche (Score:4, Insightful)
In the past, I have been the less-productive person on the team. Back before I started programming, I was working as a Mechanical Engineer. I was a perfectionist doing custom engineering work where, in the words of the engineering manager:
I was always behind and had to deal with the frustrations of my co-workers and managers. I found myself looking for work, and decided that since I had always liked computers, maybe I should look for a computer job. I am doing much better now as a programmer, where the ultimate product has to be 100% correct or it does not work properly.
It sounds like these people may just need to find their "thing," which could mean removing them from the programming dept. Regarding your current dilemna, they probably won't mind if you take over coding their parts of the project. I experienceed being removed from the engineering dept, and people taking over the parts of my project that I was behind on, and I understood why and was OK with it.
Extre (Score:2)
Many have mentioned pair programming, which will definitely help. But beyond that the prioitize, estimate, produce, analyze, repeat cycle will surely help as well.
When you miss your deadline you will have a. done all you can do and b. something that has 100% functionality on the top x% of features instead of something that has 100% of the features x% of the way to working.
Good luck.
Keep giving them smaller tasks ... (Score:2, Redundant)
Don't accept poorly written code just because "it works". If you do, you endanger the project and don't help the poor coders become better. The best way to become a better coder (IMO) is to bang away at one single problem and not worrying about doing "your share" and ending up spreading your effort too thin. When your teammates prove they can handle more coding, give it to them.
If you do it this way, you'll inspire confidence that your co-developer can do the job right. This confidence will, in the long term, be more benificial to the project and to the company you work for.
You have to decide whether they can do it (Score:2)
If they just CAN'T do the work for any reason including training, motivation or knowledge, then you need everyone to be clear about what the situation is, and get them kicked out/off of this project; you probably can't do 3 other persons work for them.
There might be ways to reorganise yourselves that might work. For example can they unit/integration test the code you've written, write test specifications etc?
However, I think your project is going to be late... Some projects (more projects than you might expect) can survive being late. Now is the time to start informing any customers you have... better start with the internal customers, e.g. the managers.
Hire me instead (Score:3, Funny)
Things to consider. (Score:2)
Reading the question, the point that sticks in my mind is that you admit to having even less project management experience than they have coding experience. Remember that as you think about replacing them with experienced people who know how to do the job they've been assigned. It seems to me that you need to stop doing their jobs and start learning how to do yours, which, like it or not, is being team leader and project manager.
Organization is also key. Read the last half of your second and third paragraphs again and tell me that you sat down and carefully organized your question. It's a careless error, but for someone who is complaining about their coding styles, it indicates a potential double standard.
What impresses me the most is that you seem to understand the solution needs to be found in management and methodologies but you don't discuss what (if any) methodologies you're using (although I'm suspecting waterfall [informit.com] right now).
Don't make them come to you. You're the leader. Be there for them, stay out of their way, and build trust. If you show leadership then they'll come to you. If you show tyranny, disgust, annoyance, or anything else, then they'll be happy to continue not producing anything in a vacumn.
Six weeks into a project with a tight deadline is not releasing code "early and often". In our world, six weeks is two iterations, each with their own deliverables, and a major iteration coming to a close. "Early and often" to many people means multiple code releases with full tests on a daily basis.
Remember, coders are no better than their enviroment. While you may have created an enviroment that works for you, it sounds like, as team leader, you've failed to create an enviroment that works for them. Perhaps it's time to put away 'your' piece of the project and start fixing the real problems.
Get a project manager? (Score:2)
"The role of project management" for a four person project is not a full time responsibility! Someone with project management experience ought to be able to do it in 30 to 60 minutes per work day.
Sell it to your management this way. There are three roles: development, technical leadership, and project management. You have time to do two. At this rate, if you do the last two and ignore the first, the project is doomed. The last one is the only one an outsider might possibly help with.
If that doesn't work, then you need to be the project manager. Try really hard to be empowering and helpful. On the other hand, negotiate the following with your boss: "If any of these three is contributing zero or negative progress, I want the power to get him or her out. Transferred to another project, laid off, whatever; but not in my way."
If neither works
Good luck!
Ahh, DSP programming. (Score:2)
I've done my fair share of DSP programming. There is a fairly high psycholofical bar when developing code for most DSPs.
First, you have the custom compilers, with their custom interfaces. It can take days for a new programmer just to learn the proper way to organize their files and on-board resources to get a "hello world" equivalent LED-lights flashing program working. Then the implimentation of C may not be completely correct, or severely nonstandard compiler errors start showing up. It isn't easy for a newcomer to just get over that and continue coding like nothing happened. All this is assuming that the documentation is halfway decent.
Next, there's the assembly layer. Oh, the assembly languages. Riddles wrapped inside enigmas, with structural assumptions that make answers seem impossible to give. It's just going to take a while, not to mention a LOT of sample code for a programmer to understand the extremely tight flow of specialty registers, limited instructions, stacks, alignments, and how they mix with the on-board implimentation of C functions and the like.
Then, there's debugging and using the DSP tools. Half the tools I've ever used on various DSP projects have been much flakier than anything you've ever seen from Microsoft. One of the first things that I had to do when getting a new DSP is to just port a set of Standard IO routines over, because so many DSPs would be out-and-out unreliable when transferring data to the PC for debug and the like. I probably spent just as much time ensuring quality communication between the DSP and the PC than I did on any one project - but this is just one of the illustrations of why starting work on a DSP that is new to you can seem such a uncertain, slow process.
I definetly agree, that if these people started at the same point as you did, then they REALLY need to do their homework, bite the bullet, and just make mistakes to get some code down to revise later. In that case though, unless you just want to call them lazy to look better than them, you really should get an O.K. from management, then take some time to teach these people what you've learned. In most projects, I'd agree that these people should at least get half the work out that you did - but on a DSP-oriented project, I'm not at all shocked that one person out of many would be able to *get it* quicker than the others... but now to get some large-scale work done, you really should see what they know, then get everyone up to speed if you can.
Ryan Fenton
sometimes you can't (Score:2)
Sometimes no matter what you do you can't bring others up to your level. There are just some bad coders out there and until they get more and more experience they wont get better. You can try teaching them about do's and don'ts, but you can't make them do and don't.
If the coders are good then often I have had to resort to pressuring them saying things like I am waiting on 'so and so's code' at a staff meeting. Basically getting manegement to step in. Sometimes you have to do that. Yes it sucks, but that is the job of a manager. In this econemy it does not pay not to work as there are plenty of people that they can be replaced by and I know of some people who would love that chance to out shine you (me ;-)).
Well.. this is rather obvious. (Score:2)
Don't you have a project plan? Some kind of schedule? Work allocated to different people?
No?
Guess who's going to go out of business.
Heres what to do. (Score:3, Interesting)
1. Quit now
2. Slack off a bit and see if the others pick up. (Your not in charge, what are you worried about?)
But you will probably do
3. Continue doing your own thing and keep telling yourself how crappy your teammates are until your ego explodes and you get fired or quit.
Truthfully, in programming this is the most important thing to overcome. People become so attached to their work. Now imagine you are on a team of professional toilet cleaners. Without the galmour theres no ego involvement. No one ever said, "I'm such a good shit cleaner, my fellow shit cleaners can't keep up. What do I do?" Its just about getting the job done.
By doing most of the work, you are fucking yourself. Your superiors are the only ones who can rectify the problem. But they won't if they expect 90% of the work from you. And you can't just reduce the work you get done because it looks like you are slacking and you take shit for it while in reality you are doing the same amount as everybody else. The only thing you can try at this point is soft delegation. Ask people how things are going, ask them about their code, hound them, not like a boss, but like someone who is interested. You can't tell them what to do but by continuously putting the focus of things in their mind, they will respond.
Probably the best solution is go on a two week vacation.
Co-Developer Appreciation Day (Score:2)
And remember, if you don't appreciate your co-developers on August 6th, the terrorists have already won.
"de-facto" team leader? (Score:2)
On this project, I have a de-facto role of a software team leader
De-facto team leader? Where's the real lead programmer? This sounds like the problem.
You're a guy who likes to code and is obviously good at it, and can obviously self-manage. It sounds like the other team members aren't so good at the self-management part. This doesn't make them useless, it just means they need to be managed. Many excellent programmers fall into that category.
The way to keep programmers productive is to cleanly specify (and by "specify" I mean really, formally specify) what you need, give them the tools/equipment they need, then get out of the way. This is the job of a lead programmer, or other manager. Not a team-mate, except in a dysfunctional project.
BTW if they really need to ask that many questions re: the spec, then you did a bad job of specifying the task.
All IMO, of course!
grib.
Management (Score:4, Insightful)
You are the leader, take responsibility for the output.
Code less supervise more, that is your new job. Break the job into manageble controllable chunks, have them report how they are doing. Check code for correctness (logical and formatting)
If you have 3 people who aren't as capable as you, you are going ot have to spend a lot of time ensuring the final work is good enough.
Also some people just aren't capable of the work, you'll have to really watch what they do.
Sounds like you need some project management... (Score:3, Interesting)
- which tasks they worked on yesterday
- how long they've spent on each task
- how much more time each task will take to complete
- what they're going to be working on today
- any blocking issues they might have
(Any design, problem solving, etc. is deferred till after the meeting, and only the people that need to be involved in those discussions are pulled in.)The project manager (who is not a developer and not a manager manager) is responsible for keeping track of the tasks and the hours and making that information available. It's always clear who has responsibility for what and who's blocking whom from getting their work done.
This does a great job of keeping developers productive, and since developers get to make their own estimates (and the total amount of work that can get done in a development cycle is based on 40-hour weeks), it also does a good job of keeping them sane.
(It works well with eXtreme Programming [extremeprogramming.org] practices like pair programming and story-driven design, too.)
My Nightmare Project... and the saveing grace. (Score:5, Informative)
Now, I am the project lead, which means that the 5 month late period falls directly on MY head. Looking back on my mistakes, I have enough information to fill one of those "What NOT to do" management books that you have on your shelf... but here is what I have learned...
1) Make short, small, and precice yet reachable goals which every team member of your team must meet. If they cannot meet these deadlines, make it known that their job is on the line if they dont have a damn good reason.
2) Make it a habbit of looking over sholders. NEVER trust that the self touted code guru has what it takes... look at their code ever few hundred lines, or every few days.... it dosent take long to glance at code to know if its good or if its crap.
3) In large groups, impliment a peer review type system. Every week, pick one guy, and pass arround a few hundred line of his code. Pick the code randomly, and you might not want to tell the group whos code it is, there will be no anger direction that way... I found that helps. If the group can follow it, (they dont have to know exactaly what it does, just follow it), then ok... but out of a group of 5, there will be one that gets it just right, 2 that thinks its ok, and 3 that thinks it needs work. Have everyone present constructive criticizem of the code format, codeing methods, commenting, and structure to the group as a whole. The whole group will learn from it, and so will the author.
4) HAVE WELL DEFINED AND DOCUMENTED CODE STRUCTURE PRACTICES!!!! I cant type that in caps enough... if everyones code looks the same, and acts the same, then if you DO have to kick one of them off the team, anyone can pick it up and run with it.
5) If you choose to pick up all the work, then people will let you do it all... the trick is to EXPECT them to do the work! Make them accountable for missing a major deadline.
6) If payment for this project is dependant on meeting deadlines to the client, then make payment to the developer dependant on meeting project deadlines. You have no clue how hard people will work when rent is on the line.
7) Just remember that your not 'Uber Coder... no matter how good you are, your not going to carry the whole project yourself and get it in on time. But if you can make your coders accountable for their own work to the whole group... then you just might make a better group.
Thats my humble advice, now... as for my saveing grace... I have had to carry my project because I learned these lessions the hard way... but the client is pleased with my work, and now, I know.
Pre-Sig : My spelling sucks because Microsoft hasnt implimented a spell checker into IE.
Hire.... (Score:4, Funny)
ballmer [ntk.net]
Some recommendations from the field... (Score:3, Informative)
These are all not unreasonable suggestions in certain scenarios. A lot of it has to do with the tradeoffs involved in your deadline. I'll tell you this: you undoubtedly need to meet with your manager at some point in time. Lay it out calmly and cooly and explain whether, in your judgement, the team has potential or is beyond hope. Discuss how you can still meet the deadline, or explain that you need to push this deadline a bit because there's going to be ramp-up time associated with getting this team up to speed.
You can be a team leader without being a full-time manager. In fact, you should be, in my opinion. A lead developer for a team needs to be concerned with project design, deadlines/scope clarification (from the technical side at least, though you don't have to spend all your time in MS Project to represent the tech team in this regard). It's better that the lead developer not be directly responsible for HR concerns, schedule reporting, and shouldn't have to be the primary negotiator with the business/requirements side.
That aside, firing people who are continually nonproductive is reasonable - but I'd push that decision up to your manager and let him/her decide that - and generally, unless this is a small startup, people get more than one chance to screw up. Personally, I think they should get two, not five or six. And they should be told that they've been screwing up - ASSUMING that they are supposed to be mid-level or more experienced developers. If these guys are junior, or this is their first job out of school, they need to be cut some slack, and your manager shouldn't have given you a team with four new kids as your first gig as a development lead.
So this leaves pair programming and mentoring. I don't think there's much of a difference, but I'll say this - pair programming is helpful even if two junior/dumb/mediocre programmers are working together. And if you are working with each of them in turn (swapping out) they WILL improve over time, unless they are ROCK stupid. I can't judge whether these fellows are rock stupid, or just inexperienced, or not good at thinking in the logical manner that programming dictates. I have seen people improve in certain ways, but I've never seen a revelation in which a shitty programmer became a key contributer.
If their egos get in the way of effective pair programming (or mentoring - well, hell I think you'll need to be doing rounds and mentoring as well as practicing pair programming as much as possible), then you will need to exercise a bit of leadership skills, and make clear to them that they are partially responsible for the team falling behind and that you all need to work together to get things up to speed. If they still resist, take them aside and explain that they are blocking progress, and you'll have to push that up the management chain.
As for the rest of extreme programming methodology - well, I agree with posters who suggest you might want to try instituting pair programming first, and seeing how that works. If you feel comfortable with that, then instituting the rest of XP for future projects might be a good idea (though I don't know how adaptable some of the methodology is to embedded systems development - it is really geared toward end user app development, IMHO). For other ideas and perspectives check out the book Rapid Development from Microsoft Press (I know, we all hate Microsoft, but there have been some good ideas for software team organization and development methodology to come out of their shop). Plus, it's definitely easier to sell management on organizational ideas from Microsoft than something like XP (though you can certainly find XP success stories out there as well).
Two orders of magnitude (Score:3, Insightful)
I've seen nothing since to suggest that this isn't true. If anything, I've seen proof after proof... Programmers who struck me as bright and experienced, yet time after time they just don't get it. And programmers who do get it. Instantly. In the first two weeks on the job.
You're not going to like the answer, but its this: Hire programmers until you find ones that deliver, and do what it takes to keep them. Fire the rest (which is to say, don't fire them but suggest to them that they should seek alternate employment quickly.)
Re:Ouch (Score:2, Informative)
"The first 90% of the code accounts for the first 90% of development time. The remaining 10% of the code accounts for the other 90% of the development time."
Re:Have the slackers fired and replaced (Score:2)
In 90% of all programming projects, given a good design and management, less people == more results.