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."
I know from personal experience that this is a good motivator.
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.
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.
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.
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.
I'd recommend pair programming in this case. Ordinarily, I think it isn't terribly conducive to getting a lot of work done, enough to justify two bodies at one keyboard. But in this case, it seems that two bodies at two keyboards is the functional equivalent of nobody at any keyboards.
Pair programming will probably make them stay on task better, since they'll sort of "guilt-trip" themselves into it. When one of them has a problem, chances are the other will know how to solve it.
Also institute daily builds using ant or somethign of that nature. That way there's no excuse for not having compiled the code--and when it doesn't compile, everyone gets a report. Another way to push the guilty parties a little harder to get their ass into gear.
I think most of the concepts of extreme programming apply to your situation. Programming methodologies in general hold back great programmers, but their reason for being is to help mediocre programmers become good (and productive) ones. I'd say this is a textbook case.
Also, having been both the 90%'er and the lazy fuckoff at various points in my career, i can tell you that motivation is everything. Pool tables and perks won't get the work out of them--they truly have to feel like a team, and feel like they're letting the team down when they slack. From your post, it would seem that you don't really feel the team effort either. I think that the most important change you can make would be to help foster that atmosphere. You also mentioned being the defacto lead on the project; don't assume that position unless its given to you by someone with authority to do so. It pisses off your coworkers.
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. =====
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!
My experience comes from managing a small (8-person) team. There are a couple of things I learned.
First, I assigned tasks. If an employee failed to complete a task, I often broke it up into simpler/smaller tasks, and requested them one at a time.
Some employees were self-starting, some required more hands-on. All required positive feedback. Even though we were about the same age, they seemed to look up to me for approval. I don't know why.
So, managing a team can mean a lot of work and coordination. I would say that in your situation, you have become the leader.
Torsten
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).
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...