Motivating Your Co-Developers?

3flp asks: "We've heard all about those coding projects where 90% of the code is done by one person. Unfortunately, on my current project it's me :-(. It's a comms DSP project with a lot of C & some assembly. My team of 4 will hopefully produce about 20k lines of code. Now comes the problem: we just got to our first small integration stage (we do try to do them early & often), and it turns out the other guys have got nothing. No code. I want to ask Slashdotters, people who have the experience with small software projects, how would you go about it? How to bring other less experienced coders up to your level and beyond? Or at least how to make them suck less, and if they get stuck on something, to just come and bloody ask for help?" This is something almost every developer has had to deal with. For those of you who have experienced this, what did you do about it and how did things turn out?

"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."

Comments

a real answer

[Jucius Maximus]

Have a manager call a meeting with all of you for the purpose of demonstrating what you have so far. This will get your group into gear. Just have the manager send everyone an e-mail that the meeting will be in room number [...] at time [...]. Don't have the manager come and ask, "what time would be good for a meeting ... ?"

I know from personal experience that this is a good motivator.

Pair Programming

[HisMother]

Two words: pair programming. Two people writing code together at one computer. One typing, one kibitzing.

See www.pairprogramming.com . If you haven't tried it (and many people haven't) your reaction will be "that would never work, and I'd hate doing it." The truth is that it works very, very well, and people like it when they try it.

By pairing with the newbies, you can mentor and monitor them Change pairs several time a day, insist that all code is written in pairs, and before long, you'll have a team of clueful people. Total team productivity will quickly rise.

As I said, if you haven't tried it, you're almost certainly going to think it's a bad idea; turns out it's not. Anyone tempted to follow up with "that would never work, PP sucks" please go off and try it for a week, first.

Re:Pair Programming

[IamSorrow]

This is part of Extreme Programming, if all you do is implement paired programming you will fail, in order for pair programming to be sucessful you should use as much of the extreme programming Philosophy as possible:

Customer Team Member - Teams have someone (or a group of people) representing the interests of the customer. They decide what is in the product and what is not in the product.

Planning Game - XP is an iterative development process. In the planning game, the customer and the programmers determine the scope of the next release. Programmers estimating the feature costs. Customers select features and package the development of those features into small iterations (typically 2 weeks). Iterations are combined into meaningful end user releases.

User Story - A User Story represents a feature of the system. The customer writes the story on a note card. Stories are small. The estimate to complete a story is limited to no greater than what one person could complete within a single iteration.

Small Releases - Programmers build the system in small releases defined. An iteration is typically two weeks. A release is a group of iterations that provide valuable features to the users of the system.

Acceptance Testing - The customer writes acceptance tests. The tests demonstrate that the story is complete. The programmers and the customer automate acceptance tests. Programmers run the tests multiple times per day.

Open Workspace - To facilitate communications the team works in an open workspace with all the people and equipment easily accessible.

Test Driven Design - Programmers write software in very small verifiable steps. First, we write a small test. Then we write enough code to satisfy the test. Then another test is written, and so on.

Metaphor - The system metaphor provides an idea or a model for the system. It provides a context for naming things in the software, making the software communicate to the programmers.

Simple Design - The design in XP is kept as simple as possible for the current set of implemented stories. Programmers don't build frameworks and infrastructure for the features that might be coming.

Refactoring - As programmers add new features to the project, the design may start to get messy. If this continues, the design will deteriorate. Refactoring is the process of keeping the design clean incrementally.

Continuous Integration - Programmers integrate and test the software many times a day. Big code branches and merges are avoided.

Collective Ownership - The team owns the code. Programmer pairs modify any piece of code they need to. Extensive unit tests help protect the team from coding mistakes.

Coding Standards - The code needs to have a common style to facilitate communication between programmers. The team owns the code; the team owns the coding style.

Pair Programming - Two programmers collaborate to solve one problem. Programming is not a spectator sport.

Sustainable Pace -The team needs to stay fresh to effectively produce software. One way to make sure the team makes many mistakes is to have them work a lot of overtime.

My Nightmare Project... and the saveing grace.

[dallask]

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.

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. :) it is a brutal tactic, but so is the business...

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.

Re:Don't be an ass.

[tongue]

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.