Slashdot Mirror
Motivating Your Co-Developers?
"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."
Block "http://www.slashdot.org" at the firewall :)
-JT
Beer. Lots of beer.
The Blaster Master Fighting for Truth, Justice, and Evil Pie since 1979
Extreme Programming works! www.extremeprogramming.org
Do you know why you make code readable and add nice comments?
;-)
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!"
My experience is that while some new programmers are destined to become good programmers, experienced programmers who don't write code rarely improve. My advice is to make sure there is tons of visibility and documentation early as to who is actually doing the work - and make sure management has access to this visibility. From that point, it's the responsibility of management to do their job and manage the resources they have. Taking this role upon yourself is usually a mistake.
Have them replaced.
There are other developers out there. Some of them actually produce code.
Number one, don't be an ass. I've been on projects where I've been treated as something less than human for asking questions. That is not very conducive to productivity.
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.
Well assuming you can't fire somebody, I guess you have to pick the people you think are actually capable of performing and monitor them frequently, via emails and daily face to face discussions, the rest, just make sure they aren't on your next project team.
Hello Cruel World
Pick up the biggest wooden staff-like object that you can find, then threaten to bean them with it if they do not produce.
Sure your'e not serious, but they don't know that.
When starting a new programmer, I find it helpful to find some similar code to let them have a look at. Starting at zero can be intimidating. Changing someone else's code is a good way to learn until you know what you are doing. Daily reviews until they get going is unpleasant, but probaby necessary at this point. Make sure your team has access to good reference books. Reduce their modules to very simple components. Newsgroups, newsgroups, newsgroups.
Speaking from experience: If it's feasible, finish the project yourself. Don't count on people who have proven incompetent.
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.
If you are capable of producing their work in a short amount of time, clearly you have an idea of how it can be implemented. Sit down with each one individually and get to finer details of their roles. Help write pseudocode, if necessary, and then let them actually bang it out. I'm suggesting, in a way, that you do it all yourself without quite doing it all yourself.
Let them know someone will get laid-off, and it's basically up to them to decide who. There's people outside lined up for their jobs, I hope they know.
M@
Krispy Cream is people
Yeah, it sucks that you are the lead of people who can't do the work, but all you can do is lead. You can't make them work. I would go to the project lead, or your manager, and say what you said here: "If others don't catch up quickly, we'll have serious problems delivering on time. " Yeah, it might not be the nicest thing to do, but you aren't there to grab each other's asses, you are there to do a job. I assume you have already given them time to do the work. If you haven't spoken to them personally yet, do so. Tell them their code sucks, ask them why they don't have anything done yet. It is your ass on the line as the lead.
My beliefs do not require that you agree with them.
You bear some responsibility for allowing this to happen. Planning for an early integration is right, but you can't ignore everything up until that point. However, now it's happened...
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.
As far as experience goes: Perhaps have less experienced people sit with you while you code, sort of like peer programming but it will be more of a learning experience for them. Encourage them to ask as many questions as possible durring that time. I think this may slow you down a bit for a while but in the end you will have more experienced developers.
I know from personal experience that this is a good motivator.
(1) People hate other people tell them that they suck at something. Whether they tell you that they are open to constructive criticism or not, they still would hate you.
(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.
Rapid Nirvana
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.
Cantankerous old coot since 1957.
I'm going through the same situation, with a developer, except in this case I need his work to be completed so that he can move on to a piece of the project that i need done, He's been developing (rather trying) a servlet that will send a file to a user. He's been at this for the better part of 2 months. I'm tired of his reasons why it's not done, so today I decided to see how hard it was to develop a servlet that does what I need (I do not know very much Java) Well wouldn't you know I have a prototype that will download a file and save it to a local directory after spending 3 hours on it, most of that time was spent configuring Tomcat and designing a web page. Now I have to explain to managment why I want this guy gone!
My solution is fire him!
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.
You can never put too much water in a nuclear reactor.
I don't think it's easy for them to "just come my and bloody ask questions" if your opinion of them is "suck" (from the "make them suck less" part). i mean... if you want the less experienced developers to feel comfortable asking questions and actually *care* about what you care about, then you'd better damn well care about them too instead of acting like (i am not accusing you of, but you may want to check if you are) an elitist who think they are just dumb ass drones.
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 life in the land of the rising sun.
The fact that "The Mythical Man-Month" says something doesn't make it automatically applicable in all situations. I mean, replacing people who haven't done anything? I don't know if you're losing much, there. If they'd come up with something that a replacement might have to get their head around, I'd tend to agree. But they've apparently done dick.
You should stop coding and force them to get their hands dirty. Do code review with each of them on a daily basis - use that to teach them how to write good code.
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.
If you've got to integration and discover that some people haven't produced what it said on the plan they were going to produce you have already screwed up. That is not how to do project management.
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".)
I have seen this happen before. The project manager, or the Department Head will eventually recognize who have not pulled their weight. This is what we managers cover in "milestone overviews". These are Pre-planned development gauges to ensure that collaborative efforts synchronize. Additionally, they provide hard data at review sessions and for salary matrixing. Motivating your co-developers is not your job, leave that to the manager. That is what s/he gets paid for. Do your part, collect your pay, and just gut it out. Eventually the less apt and inconsistent performers will be out the door. Hell, in this market there are 10 COMPETENT developers waiting for a shot.
If we don't fight for ourselves no one will.
If your project needs any small utilities or tools (such as some build stuff or file utilities) get them to do these. They can write a whole program themselves, making it a personal project they are more likely to finish.
I've mentored a number of number of programmers, successfully, at least in our collective opinion. I think the key lies in the idea that "a question well-asked is half answered."
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.
If your bitterest enemies are people who hack the heads off civilians, then I would say you're doing something right.
Organise an informal meeting. Point out to them that the success of the project is dependant on them. Point out to them that if the project fails they might lose their jobs. Ask them why they haven't done anything. If they have no real reason tell them that you cannot work like this and will have to report this to management.
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.
=== ANSWER #1 ===
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 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*
"...In your answer, ignore facts. Just go with what feels true..."
You may try implementing weekly (or daily) code reviews. People tend to work harder when they know their code is going to be on public display. Also, you'll be able to suggest improvements in smaller and more frequent increments as opposed to being overwhelmed at the deadline. Plus you'll be able to instruct everyone at once instead of repeating yourself over and over again.
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.
You don't say much about the culture of the place you're working--maybe projects are expected to take 6 months, and you're screwing things up by moving in real time? If so, there's not much you do about it unless you're prepared to do all the work yourself.
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?)
Remain calm! All is well!
It sounds like you're doing your job.
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.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
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?
There are two ways to go about this:
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....
.
"Things that you own end up owning you" - Tyler Durden (via Diogenes of Sinope).
Most of the code for our small company was written by me. When it got to be too much work I subbed some of the generic stuff to a guy who was a hard worker but not a very good coder.
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.
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!
Obliteracy: Words with explosions
First, find out from them what the problem is. Do they actually know how to code? If not, you might ask (management) why they were put on the project. Do they really understand the items they are trying to address? Are they overwhelmed with the amount of deliverables they are responsible for? Is this their first project?
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.
I think this falls under the somewhat bastard-ish things to do, but I think it does actually motivate. If you write a little script to post CVS statistics (Assuming you use CVS, or another management system.) to the intranet site (or some other highly visible location) and make sure everyone can see who is doing what that needs to, generally people will perform better. If no one is looking over their shoulder, people tend to slack off (*checks over his shoulder*, good, lets continue).
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.
Dacels Jewelers can't be trusted.
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.
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.
I can't believe that no one has brought up Extreme Programming yet!
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.
I'm surprised no one has mentioned this yet, but if you are working with a group of people and you don't know their abilities, divide the project up. If they don't deliver properly by their deadline, cut their original task in half and assign the other half to someone else (probably yourself), leaving them with less to concentrate on. Then rinse and repeat as necessary.
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.
----- rL
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.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Emebedded system, C and assembly? The other developers can't write code fast enough? If youre company is in Austin, TX, may I suggest that you fire one of them and hire me instead? I can assure you, you won't regret it.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
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 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.
No Zen is good zen
In a word, YES.
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!
In the future, I would want to not be isolated from my friends in the Space Station.
See if there's someone in your organization who can play the role of project manager: working with all four of you to break down the effort into pieces small enough to measure progress against (my rule of thumb: half a day to two days), who can track progress, who can be told about roadblocks and try to remove them.
... I guess assign busy work to any developer or developers you can't count on, document why you did so, get as much done as you can, and look for a new job. None of which is easy.
"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!
Stupid job ads, weird spam, occasional insight at
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 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 ;-)).
Only 'flamers' flame!
Are they meeting the schedule set for them, or are they not? If they aren't producing any code, what are they being paid for?
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.
Your colleagues will never live up to you, so I suggest quitting now. When you say you are the "de-facto" team leader, I'm guessing this means you are not the real team leader. You've got prima donna syndrome written all over you. You can either
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.
This August 6th, join me and the rest of the world in celebrating Co-Developer Appreciation Day! Buy them a mouse pad couch, or maybe a beer.
And remember, if you don't appreciate your co-developers on August 6th, the terrorists have already won.
Ahh, the mythical 90%. We all know the saying:
"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."
Never underestimate the power of fiber.
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.
maybe
Not that it matters if they produce "zero" code after 6 month.
In 90% of all programming projects, given a good design and management, less people == more results.
<^>_<(ô ô)>_<^>
You're in a bit of a thankless position, needing to be both a developer and a project manager simultaneously. It's a tough slog and I can't think of any easy advice to give you.
A couple things to hopefully help your future projects:
- You will need to define expectations to your co-workers in advance and in as much detail as feasible. Simply saying "we need to be done on day [x]" obviously ain't going to cut it. This involves a couple responsibilities: a) identifying appropriately detailed descriptions of expectations for each team member, and b) constructing a task list at a level of detail allowing concise definition of each task and being frequently reviewable in a meaningful way.
- More painfully, you will need to budget time into your daily routine to ensure the "pebbles" (like milestones, only smaller --not my term, unfortunately, but I can't remember who I first heard coin it) are being met on a daily basis. A basic rule of project management--surprises are bad things. The earlier you're aware of slippage, the more leeway you have to do something about it.
- Since you'll need time to monitor and review progress your own task timelines will need to reflect this. Never forget to do this, and make sure the project owner is aware of why your tasks seem to require more calendar time than other developers. You are not a 100% coding resource!
- You will need to be willing to address developers who are lagging. More specifically, you need to address them as soon as you notice tasks lagging. This isn't the easiest or most enjoyable part of the job. Note that ( "address" != rip a new anterior orifice ) What is does mean is that you will need to take the initiative to: a) identify lagging tasks, b) contact the developer or developers responsible for the task, c) determine why the slip occurred, d) identify a solution and e) follow up to ensure the solution was implemented.
None of the above is rocket science, of course. But all of it involves behavior modifications for most people. Addressing developers who are lagging in particular is sticky, since you have to be prepared for pretty much anything and any reaction and you need a lot of self-confidence to not feel nervous about initiating this contact. And, in addition, you yourself will have to change your daily work habits to some degree and be willing to commit to those changes--and this can be the hardest part of all.My personal experience is that any task with a duration of more than 2 days or so is too high level to track meaningfully--you'll have to subdivide these tasks into smaller units of time so that you can reach a meaningful agreement with your developers on what exactly is to be done and when it needs to happen. You may feel comfortable with longer or shorter ceilings. Just remember: you'll be reviewing every task frequently--make sure what's on the list is meaningfully reviewable by you.
Best of luck to you...
are computer programmers going to be forced to conform to certification standards? I have seen a lot of "computer users" try to (and sometimes succeed in) getting jobs as "computer programmers" -- in a lot of cases this involves a certain amount of lies and or embeleshments on the old resume. Imagine if Doctors or even Lawyers were allowed to wander around the job market without ever having to truly learn their skills. "Uh...I don't know how to fix compound fractures -- I thought I would only have to put casts on simple breaks and take x-rays..." I am all for written and verbal testing during the resume process. (You would not believe how many resume's and interviews I have done with people who claim to "be an Oracle or C++ or whatever" expert -- and some of them can't even do simple tasks. During the .com boom it was amazing how many people who had "mastered" HTML and Javascript walking around calling themeselves programmers. (* Most people out of work now can't program at all -- they just complain on /. about being an "out of work techy" -- We still have the same need for programmers as we ever did. Just now we need the real professionals and their is not enough overhead for the wanna be programmers.)
(+1 Funny) only if I laugh out loud.
Possibly the easiest way to get things going is this:
1. Plan the architecture. Sure, some things can be more difficult than others to get going from the start, but design as much as you can in one go, and iterate.
2. Design interfaces to match the architecture; whether it be pure virtual classes in C++, a slew of function prototypes in C, or a set of interfaces in Java.
3. Pass interfaces out to developers, based on functional areas of the code. Tell them that they're responsible for this chunk of the app, and that their job is to code up stuff behind the interfaces. If they're worried about not having other stuff to connect to (ie. it's not done yet), tell them to code up stubs that just return error codes in the right way for their own testing.
It helps if you ask everyone what areas they want to work on, and spread the load out that way. If they buy into it, then they'll work harder for you. But laying down the basic infrastructure and then delegating specific interfaces to code up is the easiest way to get others up to speed. At the very least, you can point to that person at the end of it and ask them why they haven't finished it.
Simon
Coming soon - pyrogyra
Contrary to the project management theoreticians commenting on this list, you are very lucky to have seen this behavior early. There are worse situations.
Right now you need to make the plan very visible to your manager. It's his/her problem too.
Use your management to sustain accountability for individual commitments of your team peers to the plan. If you can't get that -- leave, you don't have management support. You will need to use shame and threat and fear to get action; because goodness didn't work; your manager has to play the role of the bad guy, because you have another role ...
Help your peers to be a team and be successful. Forget coding. Clearly your part is under control. You can do it in your sleep. Don't try to be a savior. Your project has four extra bodies; be sure you understand why that staffing level was needed.
Make sure you let your management know what you are doing.
You will look like a fool or an ass if you think you can do it all. You will be much more effective if you can make this team perform inspite of its appearant limitations.
Wow, I'm astonished at the unanimity of "crack whip" as a response.
I'm going to take the questioner at his word: he doesn't know why this is happening, and has never been responsible for other coders (or other employees) before.
There's many reasons people might be turning out insufficient or inadequate code. Whether or not you think them good reasons is your call. But you need to find out what they are. It may just be that they are lazy good-for-nothings, in need of "motivation". But maybe:
Some other project has been imposed on them, and the other manager(s) are squeekier wheels? Maybe they've been working their buns off on another project. Or worse, they're saddled with administrative duties ("please restore my drive from backup!") which are absorbing their time. First check to see if something has been competing with you for their time.
They are angry at you or the organization, and they are expressing their anger in the only way they feel they can? Did you piss these guys off? Did their employer piss them off? Are the brushing up their resumes to jump ship, and just going through the motions while they job hunt?
They not coming to you with help because they think you have priorized their being self-sufficient over getting things done quickly? Do they know what your coding standards are (e.g. variable naming protocols)? Do they know you're disappointed?
They've never had to cooperate with another coder before? They are used to pulling a heroic all-nighter and handing it in, interoperability never before required?
In other words, use your problem solving skills. If there is some thing (e.g. other project) getting in their way, remove that thing. If they are having a problem you can solve, solve it. If they lack clue, impart clue. All that may be insufficient in the end, but until you investigate, you'll never know.
And ask people in ways which give them outs. "I had expected more from you by now. Have you been very busy with other things? If so, how can we get this project pushed up your priority queue?" allows someone who was slacking off a chance to realize that they were slacking off and pull their act together, without being shamed or losing face.
-*- Any technology indistinguishable from magic is insufficiently advanced -*-
Dilbert
"Did you write that code for me yet?"
"No. I'm one of those people who needs to be threatened every day, or else I won't do anything"
I mean I'm really not a manager. If I had been appointed the team leader, I'd have this same problem.
To me it sounds like the problem is that the team leader is a coder, not a leader. If it had been just one or two who hadn't done anything, I might buy that they were poor coders, but that's not what's being described here.
Without having seen what was going on, I can't say what really happened, but here's a very wild guess:
The team leader told the others what they were going to do. He understood what he was saying. It was clear to him. So he drew boxes, and put labels on them that meant something to him. Then he said, "I'll take this part", and picked the part that he had clearly specified. Perhaps he divvied the rest up, perhaps he just let them pick. Now he took a large section of the specs. But it was also the only part that he had really detailed. And nobody had clearly specified the APIs. So he said: "OK, now let's get to work!" And he did. And they went back to their offices, and tried to figure out what they were supposed to be doing. And whenever a question came up, he would either brush it off, or call a group meeting. At which nothing would really be clarified.
Everyone was doing their best, but the team leader was coding, which he could do, instead of leading, which he didn't know how to do.
Remember: I warned you that this was only a wild guess. But it's what would happen to me, even though I know better.
I think we've pushed this "anyone can grow up to be president" thing too far.
I'd just like to say
HAHA.
That's right. You would never hire me for this project or any other. Of the few managers that do interview me, none would ever consider me for any kind of coding job. Why? Because they're obviously too busy picking winners like your co-workers!
HAHA. BWAHAHA. BWAHAHAHA HAHAHA.
Sometimes, life only sucks a small fraction of the amount it usually sucks. I live for those moments.
The answer? Make sure you (as the senior dev/team lead) get involved in hiring, and ask people to code on a whiteboard in front of you, a simple problem like a linked list etc. This will have the mildly negative consequence of weeding out some good people who get stage-fright, but it will also weed out those who just cannot write any code at all. And the people who get stage-fright are also likely to suck in code review, where being unafraid of having your code publicly disected is a crucial skill. And people who don't get much review are unlikely to be great coders.
So ask the person to code a simple data structure/utility program whatever. Make the person take their time, comment their code, and ask them harder questions, language specific questions. So for example, I am currently coding Java, so I might ask them about a clone function for the list, synchronisation, serial form etc. For c I'd be looking to ask about pointer issues, and in particular work in a question about the difference between pointers to pointers vs multi-dimensional arrays with declared sub-array sizes.
You can't change what you have, but you can sure make sure the next set are better. For what it's worth, I don't think Brooks' law applies to this situation. Replacing someone who cannot code with someone who can will cost some time, sure, but it will also generate some code. I once heard it suggested that on any project of 10 or more people, you can sack one person and the code will be better quality and delivered faster. The longer I work, the more I believe it is true. And replacing that person with someone good is always a win.
...is to make design choices that are the opposite of what they want. If they say "Why did you do it this way? It's stupid!" respond with "Because I'm smarter than you." They'll go fix it themselves.
Then they should be professional, and understand that they need to be productive or they're fired.
I'd just give them all a frank speech that begins "You need to suck less, and if you don't have a fucking clue, ask me..."
dmarien
You have to manage your team better.
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.
At my company, no project starts without someone going through an writing up a memo with a list of all the tasks that need to be accomplished, and who's working on them. Now this document isn't put on the webserver and left alone, it is constantly updated to reflect changes; people ahead/behind schedule, new tasks, ect. Every new version is published, in pdf form, on the webserver, so that anyone can see what goals need to be met.
For each of the tasks that is non-trival the programmer doing that task creates a spec for it so that we can reuse items (if there is a similar spec on the webserver) and that everyone knows how their portion of the project should run.
Also, we have a perfect project bonus. If you get a complete project done, on time only (becuase if you mis-estimate, you cost the company money, even if it such that you get things done faster than you said,) you get a 5x to the regular bonus for new products. This motivates the project leaders, and their programmers fairly well.
With this, it is required that each programmer have a measure of flexablity in how they get their portion done, typically we create a suite of tools and then glue the suite together with a controling program (it is the project leader's job to make that program, as they should know what each of the parts do.)
When I'm not working, I have hit the same problem with some opensource software I'm writing. I have taken it upon myself, as the other person cannot help much, to write everything my self. I've decided to do it that way, so that I know the code is correct and in the same style.
Sometimes you have to do it all yourself, but if you are paying someone to write code, then they better be doing what you are paying them for.
=================
Unix is very user friendly, it's just picky about who its friends are.
Problem solved.
Compare the code against the requirements and coding standards (if you have any; if not GET SOME). Read through their code line by line. Point out any actual mistakes or violation of the coding standards, and write them down. DO NOT COMPLAIN ABOUT ANYTHING THAT WORKS BUT ISN'T THE WAY YOU WOULD HAVE DONE IT.
Check that the list of problems are fixed. Start integrating...
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"Get to know them, take them to lunch.
Some people have a hard time coming up with original code. Give them a skeleton to work with.
Help them do the design, in a very concrete way. Your goal in this part is not to do it, but to lead them in doing it. Remember it's their code, not yours, so they need to come up with it, as painful as it may be to you.
Don't think that just because they say the right things, they actually understant what they say. Too many people know the right words, and can even put them together in sentences.
Despite what some others have posted (cover your ass, by making it you're bosses problem), show some initiative by solving this yourself.
Don't think you're boss isn't aware of this. He either can't think of a solution or is seeing if you can solve it.
Spend your free time working on their part of the problem, then the working day helping those get their part done, in their own way. Yes this is a lot of work, but it will enhance your skills at leading projects. Eventually you'll learn to do this without actually doing the work before hand.
If all else fails, start to yell and scream. Sometimes a boss has to be an asshole.
massive quantities of free caffine?
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
If you are capable of producing their work in a short amount of time, clearly you have an idea of how it can be implemented. Sit down with each one individually and get to finer details of their roles. Help write pseudocode, if necessary, and then let them actually bang it out. I'm suggesting, in a way, that you do it all yourself without quite doing it all yourself.
If you do the above rather than simply going off alone and finishing the project by yourself you should really impress your bosses and most of your co-workers. I would pair-program with each of them on a rotating basis and ask the remaining 2 to pair program with each other. This will allow you to quickly asess where each of them is at. I would also put into place some of the things that are considered "current best practice" in the industry such as daily checkins, daily builds, and weekly or even daily code-reviews.
Happy Fun Ball is for external use only.
"Team Leader" who goes and locks himself in his office and bangs out code isn't being a good team leader.
In other words, just as they're not up to speed on their tasks, you're not up to speed on yours. Looks like there's learning to be done all around. :-)
Vintage computer games and RPG books available. Email me if you're interested.
- 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 practices like pair programming and story-driven design, too.)
-- Some things are to be believed, though not susceptible to rational proof.
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.
Lasers Controlled Games!
One of the big problems with geeks is that they can be assholes, as you may witness by some of the replies to my first post.
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.
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....
Sometimes the best solution to morale problems is just to fire all the unhappy people.
I am going to assume that they are newbies, and getting paid as newbies should. Fix that first because you care most about your company's bottom line.
When I was a newbie in a small consulting shop I faced many of the problems your co-workers have. I had no clue about the librarys I was working with (in-house, ObjectARX, MFC,..) and was too stupid to ask for help and spent all day in with my head in a book trying to catch up to speed. As long as they are newbies you become the mentor. Break projects down 1-2 day chunks that they can work on without too much trouble. Meet with them a few times each day to see if they are stuck on anything and encourage them to ask lots of questions. Also, since you have a group of them it might be nice if you split them off into pairs for some projects so one could research questions they have while the other codes. Rewards are also good. If they produce some good code show it off to others. Sometimes newbies have an attitude that they don't want to screw things up, and a little confidence goes a long way towards them beliveing in themselves.
bash-2.04$
bash-2.04$yes "Don't you hate dialup connections?"| write USERNAME
Most important of all: remember that they are human beings. They're just like you. They're not merchandise, they have feelings, they think, and they're able to do good as well as bad.
Having said that...
Why did they behave like that? I would understand if it happened to one of them, but to all, except you? Something must be wrong; are you sure you're getting the full picture? Talk to them, find out what's going on.
Do they like what they're doing? Do they want to improve? Do they want to learn? If they do, there's hope. Maybe you could pair with each one of them, and coach them. Also, get them to buy some good books, like Code Complete, The Practice of Programming, The Pragmatic Programmer (yes, I think it's a good book), etc.
Of course, there's the deadline -- will someone die if it isn't met? Is it really critical? Or does it reeeelly, reeeelly has to be done until 'x', because someone says so? If it really is critical, then there's no time for you to coach them. But I believe that, the way things are, you won't meet the deadline, anyway.
If they aren't interested, then I believe they're at the wrong job. Maybe you should make that clear to them. Life won't get better for you or for them if they remain where they are.
Oh, and remember that in your hands there's the power to make those people better than they are now. Try taking the chance...
Comment removed based on user account deletion
I certenly feel your pain, I am currently the driving force in a 60,000+ code project. We (three of us) have speent a year on this project, and as of today, I have written 52,000 lines of code... and debugged all of it.
:) it is a brutal tactic, but so is the business...
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.
The Code Ninja is swift with his tool, precise in his delivery, and deadly accurate in his execution.
If you read that book you'd realize the scope of TMMM is that of a 100+ person project (s390 IIRC).
With the scope that THIS article is talking about, getting a replacement may be neccessary
The main problem I have is when I've lost focus on a project, mostly this is a internal political problem at the company, that causes a project that a developer designs to be completly retrofitted by some marketing f*ck who dosen't know what he's doing.
:).
Once that happens, the project goes downhill. It dosen't *always* happen, it just *usually* happens.
What I find is that if you give each person of a group a rough idea of what they have to work with and what each chunk of code has to return or do, it will get done. Once you start spoon-feeding it to them, they no longer care to complete the project (multiply this by 1,000,000 if the person spoon-feeding is not technically inclined).
Of course, I would have absolute faith in my employer under all conditions if they did things for me more offten, like random "take a day off", and mabye the occasional cash bonus at the finish of projects, but it just isin't going to happen and that's why most programmers are just hired guns, going to whatever job pays more. Having faith in my employer would most certianly give me a sense of purpose while listening to the mindless drivel of a marketoid trying to figure out if blue or red is a better color for a text box (actually happened to me, I interrupted the meeting and asked if I should go fetch a box of crayons for them to decide with, this didn't help
But then again, isin't some kind of faith in your job what motivates employees at most companies?
*shrug*
Just my 2 cents.
You could steal their red stapler. That always seems to motivate people.
Who made the estimates on your little project, you? Did the sessions go like this:
"Ok, this part is so easy, so very easy. You just need to do blah blah blah blah. Get it?"
"Umm, yeah."
"Ok, how long will this take?"
"I'm not sure."
"Lets say 2 days."
"Ok."
Lo and behold, they don't have it done in two days.
The very fact that your idea of an easy solution is just to code it yourself says loads about you.
You say that its very obvious that they understand what to do, because you've had "discussions". There's a little thing that we real engineers (Yes, thats engineers or developers, not "coders") like to do. We write "specifications". If you had written specs, or had them write specs, these problems would have come up early.
No, I know you very well. You had lots of "discussions" where you basically came up with a clever system all on your own, using terminology and technology you were familiar with. Then you disappeared for two weeks into your cube, eating potato chips and rocking to mp3s on your noise cancelling headphones. Then you popped out, and were shocked that nobody had coded the design in your head as well as you had.
My intern wasn't working the way I needed. So I asked my boss what should I do, and his answer was pretty clear:
"Sometimes, you have to act like a boss".
This was the only thing that he said... so simple.
Buy a Nintendo DS Lite
My experience has been that if someone has achieved some modicum of success over the years (e.g., he or she hasn't been fired), then nothing short of harsh action is going to change that. There are lots of people who will totally coast whenever possible, and lots of jobs where they can get away with it. Once ingrained, nothing short of fear for his or her livelihood will change that.
At my last job, I kept vouching for a co-worker whom my boss felt wasn't worth keeping around. After initially giving him the benefit of the doubt more than anyone else (I was really the only one actually working with him), after a while I came to realize my boss's impression was correct and I had lots of talks to my co-worker about his productivity, etc. I ended up being appointed his supervisor (we were first hired as equals) but even that didn't work. He ended up giving notice the day I recommended he be canned. In general, I think I put up woth a lot more than I should have because he was a nice guy and generally seemed to be trying hard and the project we inherited was the worst code either of us had ever worked with (discounting perhaps the 1000-line dBase routines written by the boss's nephew I had to untangle at my first job in the late 80's), but given that we were swamped with work and I could never count on him to get anything done, and _then_ he started doing things like not showing up and giving lame excuses, I had no choice to recommend replacing him, and believe me, it was not an easy decision to make. Anyhow, it's clear he hated it there (so did I, and I left 6 months later), and him staying was doing no one any favors.
Once crisis-mode hits, I'm afraid to say that based on my experience it's too late to fix problem workers.
You are in a maze of twisty little passages, all alike.
I would suggest the following as the normal way you should work with your team --- You will be amazed how much things improve.
1. When you assign some work ask them to plan and estimate their piece of the work. When they think about what they need to do, they will naturally ask questions -- and give you an opportunity to help. Stress the importance of their understanding what they are trying to do and thank them for clarifying the spec even if you think they should already have known what they asked.
2. REQUIRE absolutely that they break the job up into small (40 hours and better yet 20 hours) pieces that they can unit test (what a concept!)
3. Gently hold them to their estimates and when they exceed them, point out that developers typically underestimate by 30% until they get experience doing it. If they beat them let them know they did something neat!
4. Follow up with them on a daily basis and ask how they're doing -- encourage them to alert you to problems early and then help them through the problems.
5. Adopt coding standards. Just pick one -- the use of any standard is better than no standard at all.
6. Plan code reviews for various modules -- start with really good ones and identify and praise the good parts, then go on to weaker ones. Avoid direct criticism and don't do code reviews until you have read and practiced the methods of doing code reviews (being considerate, gentle, and framing criticism in non-negative packages are a good start)
7. AND MOST IMPORTANT - look in a mirror and tell yourself to do the same things! Look at your work and your estimates and start improving them.
Seriously, best advice is to take a good hard look at your situation and surroundings and make an honest assessment about whether you can succeed in that environment. If you come to the conclusion that you are doomed to fail cut your losses and get out if you can. Don't throw away good time after bad.
Hopefully the rest of the advice on this page works for you and you can ignore this. Please don't just discount it out of hand though - you sound like a the honest hard-working type and I hate to see good people wasting their time and damaging their careers.
Davo -- Free speech, free software, AND free beer.
But that's water over the dam. You have a project you need to get back on track -- and fast. The first step: have you told your boss? I'm not talking about blaming the other guys, I mean expressing a concern about the project schedule. If he finds out the hard way, he's going to be peeved at the project lead. (That would be you.) If you warn him now, he might actually be able to help. Perhaps he can assign additional resources, change project schedules or at least warn his superiors that there is trouble brewing. Any manager worth his paycheck realizes the value of having employees who give him a heads up when there is a problem that needs to be addressed.
Next, sit down with your coders and talk out the problem. Again, don't let it come across as blame or they'll just get defensive. Make sure they understand the schedule and what the problem is. Maybe they can work extra hours or maybe there are problems they haven't mentioned. In either case, try to come up with a work plan that meets the schedule or comes as close as possible. Include some form of accountability so you'll know if the schedule is going to slip again.
Finally, you're probably going to be clocking in some late hours. Keep an eye on that and make sure you leave the office when you have to, regardless of the schedule. Killing yourself won't get the project done and will just make the schedule slip worse in the long run.
Illegitimati non carborundum. (Don't let the b******s wear you down.) :-)
Good luck.
===== Murphy's Law is recursive. =====
I agree about pair programming. In fact, *YOU* as the lead should pair with the other developers, so that you can guide them and maybe find out what the problems are. Spend a day or two with each guy/gal.
The other thing is to make everyone write unit tests, and if possible setup a continous build that compiles everything and runs tests everytime someone checks code in (you are using source control, right?). There are many OSS tools that do this and send email when things break (compile or tests).
Then everyone will get a feel how the project is going.
Don't hog the good work for yourself, just because you think you're much better. Somebody else should know the code too, or else you'll never get any vacation.
...richie - It is a good day to code.
.... this motivational speaker for developers:
ballmer
Okay, it sounds like what you really need to do is implement weekly status meetings, where at a particular time and place every week, everyone gets together and shares what's going on. The meeting doesn't need to be very formal, and trust me: doughnuts can help keep people in a good mood, and don't cost a lot.
But at each meeting you should have everyone go around the table and describe what they've worked on that week. Describe where they are in the code, how they're doing, any difficulties that have arisen. The meeting should never be judgemental; instead if someone is taking longer than expected, see if others can offer solutions or help. The whole theme should be group coherency; no-one is an island and no-one gets left behind or allowed to sink.
If you do have these meetings, it may be best to place them on a Thursday; that way people are motivated Tuesdays and Wednesdays to do something so they have something to show. And that way, they feel like they can have some breathing room Monday and some time Friday to either catch up or slack off, depending where they are in the project.
But always have them; insist everyone is there, and insist everyone share where they are. The meeting itself, if handled weekly for a small group of people should take no more than half an hour, so there is no excuse for the thing sucking down an entire day. And for God's sake, no presentations! Just an informal chat with the entire team there over doughnuts to discuss progress on the project.
From the description of this particular situation I would have to say this is 90% a project management issue.
Are there no schedule with individual milestones? Keep in mind that the designer (not coder as any schlock can lay down code) should provide input on time lines (e.g. sure, that date is reasonable for that goal...etc.).
Projects also have to be monitored and have schedules updated to reflect reality and/or make necessary changes in work division.
Also, use a tiered design approach; ie. high to low level. This way yes, the requirements & application domain are spelled out, but each design documentation layer brings the next level of gritty details to light. So, in terms of S/W design, a high level design document for the overall architecture. This makes it clear as to how components are connected and related. Then go down to document the individual module designs. These highlight the intent of how a module will perform it's function. With this in hand coding almost becomes trivial.
Now a documentation trick that I picked up from a great mentor in DSP was to use different levels of pseudo code in module design documentation. High level stuff that is to be implemented in high level languages and is not too harry (ie. not some convoluted DSP algorithm) can use a very general level of detail in the pseudo code. E.g. Enable echo canceller AND run state machine Y. However, if one is documenting something to be implemented in assembly (particulary harry DSP algorithms) then use a detailed level of pseudo code that is equivalent to say C or some other high level language. The idea is that the intent of the implementation becomes easier to verify prior to ever writing a line of code. Overall, this also means that people have thought out how things will work in great detail and this has been reviewed; ie. at the design documentation level. This also simplifies & improves the effectiveness of code reviews since the design intent is well documented.
Which reminds me: code comments should describe the _intent_ of the code and not what the code actually does.
As for bad code, that is what code reviews are for. Now bad code in DSP can be very nasty, particularly in assembly as one incorrect shift can cause huge problems and be very difficult to find.
BTW, I'd recommend simulating the code after a code review and it's fixes, to help ensure code sanity.
I've also seen enough DSP and other "interesting" domain code from people with Masters and even PhD's that is pathetic as far as good code is concerned. I have also worked with brilliant people with this kind of background that seriously put us mere mortals to shame.
If your designers are really that poor at coding and you do have the skills then I would suggest a frequent level of mentoring. A positive atmosphere and some mentoring can go a long distance in terms of improving a designer's abilities.
Anyhow, good luck!
Who the hell hired those idiots? There are too many GOOD programmers looking for work to accept this excuse. Whoever hired them should take the responsibility as being the principle cause of the failure, and replace them on the spot. GOOD programmers can pick up on a project fast. Afterall, this is only a 20K project. That's relatively small. So this will set you back at most another month. Just do it. Please don't encourage BAD programmers to stay in the field.
now we need to go OSS in diesel cars
At the risk of sounding like an arrogant ass (or at least, as arrogant as the post I am replying to), it is generally not your technical/coding abilities that get you the work - it is your ability to work well with a team, to communicate. Soft people skills are far, far more important than technical skills.
Why is this true? Because anyone who's worked as a professional programmer knows that your technical skills are constantly evolving - approaches to problems are constantly being refined. But if you cannot communicate effectively with other people, your technical ability doesn't matter. The key is to develop both sides of oneself - be an amazing programmer with amazing communication and people skills, and watch your career take off.
90% of every job I have ever had involved taking requirements from non-technical people and translating that into technical reality.
Actually, he said "co-developers" and "de-facto role of a software team leader."
What this really means is that Our Hero's manager is weak, a guy who wants to limit his own accountability by blurring the lines of management. He won't acknowledge Our Hero's management role with an actual managerial title or compensation, yet he will continue pushing project responsibilities onto the poor, inexperienced guy.
This allows the manager to take credit if it works and to avoid blame if it doesn't. Been there, done that. In the long run, no matter how this project turns out, Our Hero will still have the same bad boss, and he'll be in this project situation again and again until he gets a different boss or redefines his role up (into management) or down (back into coder-only).
He looked at me and said, "Kid, we don't like your kind, and we're gonna send your fingerprints off to Washington."
Look for a way to make your co-workers succeed rather than putting effort into documenting their failures. Otherwise, you'll perceive yourself as working with "idiots" the rest of your career.
I know how I would react. I would ignore that everyone else wasn't doing anything, let the project run over, and eventually do all their coding myself. Single person projects are so much easier than multi person projects.
Everybody makes exactly the arguments you're making, and the fact is, they're all wrong, they simply are.
:) Anyway, I've been to the website, and I'm still not convinced.
:)
Prove it.
And although being "in the zone" is fun, virtually all code written while "in the zone" sucks.
My best code is written while I'm in the 'zone' state. If that's good or bad is another topic.
than to code something quickly while high on caffeine, sugar, and lack of sleep,
Ahh, maybe that's the difference. My 'zone' does not rely on any of that, and doesn't last more than, say, 6 hours, because I usually don't stay at work longer than eight, and I have to have time to eat and read Slashdot.
As a Computer Science student (one year left), I took a software engineering class this past semester that was basically about the different models and processes of a project. While the waterfall model and others were used and introduced, a variety of techniques like XP were taught as well. The advantages and disadvantages of different development techniques were addressed, along with material on how to find the right process for a given task.
Although acceptance can be slow, schools *are* teaching this.
Never let anyone go off and code on some large single task without keeping a good eye on them. Micromanagement is often a dirty word, but to manage multiple coders that are supposed to be all working on the same project, you need clearly defined and intricate goals. There should be meetings and code reviews at least once a week. Integrations should be staged, as you said, "early and often" that means at least weekly, up to daily if applicable.
Any slackers then show up early and they will end up being hounded (maybe by you, or the rest of the team). They either shape up or get replaced. There aught to be plenty of people looking for jobs these days.
One would hope that the idea of remaining an employee would be enough motivation to start pulling their weight. Beyond that, generally a coder works better if they believe in the project and believe in their team mates and bosses and have a generally friendly atmosphere. But I got to say, these days that luxury just isn't as prevelent as it used to be.
Also, even if they are coding. Keeping good track records of performance and code quality is also important. Basically, if you've got lazy programmers they will get away with what ever they can. Just don't let them get away with anything for any length of time. Don't wait until it can even be a problem.
Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
Unfortunately, the best coders don't always make the best managers. I've seen extremely good coders fail to manage efficiently, usually for two reasons: (1) They spend too much time coding, and not enough time managing, or (2) they simply aren't good managers.
The original poster is in a bind, as he's being forced into a position to wear two hats without adequate resources to manage both. My suggestion would be to put the ball back in mgmt's court: Make it clear that you will either play the role of developer, or the role of team lead, but not both (unless adequate resources in time and pay are allocated).
Continuing down this track is simply giving mgmt what it wants: Two job descriptions filled for the price of one. Your performance suffers, while the bean counter who made this ludicrous decision wins, at your expense. You are being used, plain and simple.
Just say no.
Do your co workers care?
Simple point, after this project, if you have shown you are the brains and brawn(let us hope) then you will stay with the firm. Look long term. You have shown from posting your comment that u care. That is important. Many firms die to hire empoyees who care and know what they are doing.
As for your co-workers, Try and get em to take part, they may well be genuises at keeping code together after the end of a project, brilliant at making sure project bosses implement the right thing(damn good communicators), you might not like doing doing all the work, but are you a team? You say they aren't completing, I hope u are experienced enough that completing is not all.
If u are my sympathies.
Most folk I have worked with reallly did not like being shown up, but I learnt from them, I showed that I learnt from them. Then all of a sudden they were level with me. Thinking they were not just left behind, these guys/gals learnt from me, thinking that they therefore can equal him me . Some one mention
Enjoy, well never give up.
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).
Employers look at this and say "What!? You want to dedicate 10% of our programmers' time to looking at code?" But they miss the point.
With code reviews, people become accountable for their code, and it quickly becomes apparent who is and isn't producing. This motivates people who don't want high visibility as slackers, and makes it easier to prove a case when you approach management about replacing somebody.
Says the RIAA: When you EQ, you're stealing bass!
If you're the project leader, the blame rests squarely on you when your superiors ask you why it's not completed! As such, there are two things you can do to make sure the project is moving along:
there are two kinds of uber-programmer:
A) the kind that does everything 'THEIR WAY', and no-one can follow it, thus they are bad for a team
B) The kind that is simply a better programmer than most people, and can get good things done faster.
Sounds like you have had too much experience with the former, but the poster is one of the latter.
Show me three useless programmers....
And I'll show you two testers and an aspiring manager!
Opinions on the Twiddler2 hand-held keyboard?
I must respectfully disagree with you - this guy needs to get these guys fired NOW, while at the same time explaining to his bosses that the schedule IS going to suffer in the short run.
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.
www.eFax.com are spammers
Back in college, a professor told me that there are up to two orders of magnitude of difference between the the productivity (as measured by debugged lines of code) of the basic "competent" programmer and the guru. Two orders of magnitude. For the math impaired, that means that the genuine guru delivers in a week what it takes the entry-level programmer a year to produce.
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.)
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Between an inexperienced developer and an incompetent developer. If it is because they are fresh out of school, but you can see they "got it", that they are brilliant, feed them with all the code and the algorithm etc etc that you can. If they are freshies, and they want to learn, they will grasp things really fast and will learn new concept at an inimaginable speed, becoming productive pretty fast.
If they are just incompetent, ("senior" VB developers who can't even subclass a form or "senior" java developer with "10" years of java coding who have never heard about design patterns for exemple), then you are just in deep sh1t...
I'd rather be sailing...
I don't think they do. Coding is the process of explaining to a computer something that you already understand.
If you have THREE programmers, presumably with some experience and an understanding of their tools, with NO useful code, then you have a communication problem.
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.Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
As a CTO in charge of a number of programmers, of various skill levels, I've found it's good to vary the method I use to define the problem. For really good programmers, it's enough to tell them to "solve x and produce y." For lesser programmers, it's helpful to write the steps out explicitly, i.e., "do step one and produce x1, do step two using x1 and produce x2...do step? and produce y." I personally write the steps (as comments) for these programmers. If needed, either I or one of my better programmers, will write tests for each phase to ensure the code meets the standard. You may find that, using this technique, "marginal" programmers are capable of producing good code. What they lack is the ability to see the big picture. So, break it down for them.
The world of achievement has always belonged to the optimist. -- J. Harold Wilkins
if you can afford it, stop being productive and do the architecture work. flesh out as much of the guidelines as you have to and leave out the detail. (even though it may be just an easy 5 minutes for you to finish up the job) our principal failing as managers is that we don't communicate. be clear by building out the framework everywhere, it leaves little chance for the beginner coder to get lost and it keeps him on task. think through all of the major paths for a project before-hand and let your staff come in and fill in the details. this will virtualy guarentee that your coders won't "code against the project". then set clearly defined goals and let the team thrive on the emotion that comes with their ideas for refinement of your roughed-out dream.
i'm not convinced that peer review is worth it mid-project. it has it's place but it detracts from the emotion you are working on preserving. most slow and steady coders don't have (nor want) the big picture in their heads as they work. make that be your job. play babysitter and error on the side of communicating too much by example. if a coder is still not productive, make your team smaller.
just my $0.02
I think you pretty much hit it on the head, right there. Management who are not programming literate are all too likely to use a bad metric (such as number of lines of code written) to judge a project.
It's true that a top hacker might produce code at a rate several times faster than Steady Eddie. Far more important, though, is the quality of the code written. A really good guy will probably spend most of his time thinking and experimenting, rather than writing final production code. Only when he's got a rough design that he's pretty sure is workable will he write the code itself. It's quite possible that this production code will actually be shorter than what Steady Eddie would have wound up with, because he's got a cleaner design and implements it efficiently. The good developer's faster rate of production comes from the speed with which he gets to the end point, not the volume of code he produces.
The task before the management team -- who are really the guys responsible if this sort of mess happens -- is to adopt effective metrics for judging the competence of their staff at the various tasks involved in the project. Only after doing so can they redirect their resources to where they are most useful, or if really necessary, take steps to get rid of the incompetents or prima donnas who are genuinely doing more harm than good.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Sustained long hours working is never productive. This has been shown time and again in studies on the subject. Anyone who thinks getting programmers to work 50+ hours per week is going to produce more than the same team doing a comfortable 35-40 is just suffering from wishful thinking. You can flog a dead horse, but it still won't get you there any faster.
And of course, a heavy overtime culture is damaging to everyone in your company, good guys included. I immodestly consider myself an above average developer; I get the jobs done that are asked of me, and I try to do them well. I accept that in this industry, sometimes deadlines happen and a bit of extra effort is needed to make it. I also expect that if I make that extra effort, it will be recognised, and I will be compensated for it. To a point, I don't mind whether this is with shorter hours after the deadline or some sort of reward as a thank-you; it's the principle that counts.
An employer who treats me well will get my loyal service and the best work I can produce every single day. I consider this my professional responsibility, and I take pride in my work. OTOH, the day any employer tries to take advantage of my good will (or force me to act on a contract clause that claims they own my soul) will be the day before my resignation notice prominently hits the desk of the most senior person I can find, with a detailed description of why I am leaving. I have been told by worldly wise fellow employees in the past that I'm just being complacent or arrogant in making such claims. They still work for shitty employers, while I work for a place where the respect is mutual. I think I'm winning.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
If that were true they'd have code...maybe not what would work but at least some code. If they've not produced anything, and NOT come asking in 6 months then it is time to wish them luck in another field.
errr....umm...*whooosh* *whoosh* Is this thing on ?
So, in 2 weeks they got nothing done. Possible causes:
1. Lazy.
2. Assigned tasks over their heads.
If it was #1, then your management gave you a bunch of losers for the project. If it was #2, your management probably suffers from #1.
Death by management failure. Very common.
HAHAHAHAH my fortune for a mod point :)
Karma Clown
OK, well this post is much too late, but possibly the author might find it and read it.
You say you're the "de facto software project team leader". Who is the "de jure" team leader ? Who is meant to be doing the work you're doing ? If you have someone who's meant to be managing the project or providing technical leadership, and they're not doing their job, you need to make sure their boss knows about it. Have a few words with them first about your concerns, and if they don't act, go to their boss. I know it sounds harsh, but I've been in your situation, and it is a hiding to nothing. Noone gives you any credit for doing a job if they don't know about it.
If your place of work is relatively unstructured (as mine now is - I prefer it that way), and noone has an official leadership role, make sure your ultimate boss knows what you are doing. Once again, you don't get any credit for doing a job if noone knows about it. You're an employee (I assume), and ultimately the success or failure of the enterprise isn't your responsibility, although, of course, your job is.
If you're pretty confident that you have the responsibility of sorting out your project, then you really do need to sort out the problems you are having with your cow-orkers. It sounds to me as if they're either lacking in motivation, or not very good coders.
There's a judgement call to be made here as to whether these people are redeemable. They might not be. Some people just aren't up to programming, others require so much effort to train up that it is not worth the investment, others are unmotivated, due to personal problems, in such a way that you can't help. The only answer is to let such people go. This is why you need to be in a position of authority acknowledged by your boss. I don't necessarily mean that they need to be hurled bodily from the doors, but they need to be moved to work that they're capable of doing. When it comes to hiring new people, make sure you're involved in the process.
However, the only way you're going to find out whether your cow-orkers are redeemable, is by trying to help. If at the end of that process you,ve acheived nothing, then proceed as above. In order to help, I'd suggest some or all of the following:
1. Make sure people are motivated. They need to know what your project does for the company. They need to know what they, personally, can expect to gain from success. If - as is common is technical organisations - there's not real career progression opem, you might want to try to fix that.
2. Make sure they know what is required. That is: what must be delivered and when. They should feel that it is a team goal, and that it is acheivable. They should feel personally responsible for their bits.
3. Track what people are doing, on a day-to-day basis. Go from desk to desk and ask. Help with problems. If people have gaps in their knowledge or misunderstandings, talk them through it, rather than just telling them answers. If there are problesm with the rest of the organisation, try to sort them out.
4. Institute code reviews or pair programming. Make sure you are involved, but encourage them to critique one another's work and improve on it.
5. Change the way you're scheduling work to make tracking easier. Expect people to deliver demostrable units of functionality every at least week or so.
6. Never lose your temper or act in a condescending manner.
It's possible that your design or execution of your part of the program makes it difficult to write the others. Not for you, since you know all the tricks and hidden invariants of your code, but for others, who don't understand what you're doing. The key to successful team programming is carefully defining modules and interfaces between them such that they can be implemented with minimal interaction and understanding of the other programmer's code.
Anyway, I am probably just guilty of giving the benefit of the doubt to your co-workers, but don't overlook the fact that your personal code output is not the only measure of how good you are for the project.
If you need a quick fix, I suggest taking a few hours with each other team member and getting them started on their code in a pair. Programming in pairs (the best idea in 'XP') is pretty good, and it usually results in high knowledge transfer and low bugs.
And sit back and relax at your current one in the mean time. Y'all are screwed, and when the project doesn't get done it's doubtful you're going to be spared.
Actually, 90 percent of the programmers haven't experienced the problem of being in the 10 percent who do most of the work. They have, by definition, been in the 90 percent who do 10 percent of the work.
Eternal vigilance only works if you look in every direction.