In the land of the blind, the one-eyed man is team leader

May 11, 2006 8:41 AM

"Managing" the development of an application: I'm the lead developer on a project that has swelled to 6 people. How do I smartly break tasks up into discrete chunks, assign them to people, get accurate estimates of how long it takes someone else to do something and track their progress?

I realize each piece is a Holy Grail of development unto itself. I have trouble enough providing accurate estimates for my own work, let alone that of someone junior to me I've never worked with before. I'm just hoping to get ideas on how other people have managed to herd a bunch of other developers while maintaining a consistent project vision and writing some code of your own.

The project is being written in C# in Visual Studio 2005 if that helps. There's an object model and I've tried to use that as the foundation of breaking things into discrete pieces ("discrete" here being a stand-in for "something someone can work on without interfering with someone else"), but I'm doing a lousy job of it.

Also, should I feel guilty about not writing enough code? The overhead to this is way more than I imagined, so I don't know if I should concentrate more on making everyone else write good code or trying to lay enough foundation in front of them they can't fuck it up too badly. I don't want to be The Architect who thinks great thoughts and never gets his hands dirty, but I don't know if doing both is feasible either.

posted by yerfatma to computers & internet (14 comments total)

First MS Project is your friend. It's an effective tool for managing resources and scheduling.

How do I smartly break tasks up into discrete chunks

This should depend on your software design. Generally the discrete chunks will break down to software functionality. This will also drive scheduling. Figure out what you need first so that you have a foundation to build from in subsequent tasks. I do mostly web dev work so usually this breaks down to things like DB abstraction, beans etc and moving towards the front end from there.

Don't try to reschedule every task. Early on when managing it's best to just try to break the project into 4-5 milestones instead of extremely discrete goals. Rely on your team a bit more to schedule their time wisely and to give you good estimates of their time. Most will pad their own estimates so padding this may be up to you.

Also, should I feel guilty about not writing enough code?
No, you should feel guilty if the software design is weak or poorly implemented. Don't feel guilty for not being too hands on, you'll wish you were doing more code and less managing later on.
posted by bitdamaged at 8:54 AM on May 11, 2006

Joel has some thoughts.

Figuring out how long it's going to take you to do something is a skill that needs to be learned. You're going to have to ask your developers for time estimates, and if they're wrong, call them on it. Don't pressure them to work faster, pressure them to get their time estimates right (again, I stress, not by working hard to stick to the estimate, by being right about the estimate in the first place).
posted by Capn at 9:11 AM on May 11, 2006

Also, should I feel guilty about not writing enough code?
Holy balls no! You're not a developer anymore. You're a lead developer. Your main job (IMO, your boss might have different ideas) is to enable your people to turn out their best work. That means scheduling their tasks and shielding them from all the crap from upper management and other departments. Your motto should be "tell them to talk to me".
(At least, this is the manager *I'd* like to work for)
posted by Capn at 9:15 AM on May 11, 2006

Assign people based on their area of specialization.
Learn about software based project management, there are some good books like Code Complete that discuss this.
Use software patterns to break up functionality and to avoid recoding things a million times.
posted by blue_beetle at 9:18 AM on May 11, 2006

Early on when managing it's best to just try to break the project into 4-5 milestones instead of extremely discrete goals. Rely on your team a bit more to schedule their time wisely and to give you good estimates of their time.

I did the first part originally (breaking things into larger buckets rather than trying to be too fine with the details), but I made the mistake of applying my own estimates to that.

To give a little more background: there is a project plan in MS Projects, but the dates have long since been blown up by the client demands on another project (same client, different project), so the team has shifted from myself and one other person to me, 3 other folks and whatever other help is available week-to-week (which skeeves me out re: The Mythical Man Month problem of adding more people increasing time to complete).

This isn't my first rodeo and I hope I'm not as green as I sounded, but this is all great advice. Some of my problem is getting feedback from the other developers. Of the regulars:

1. Is totally new to the company, so he's a mystery.
2. Is good but really quiet. He works quickly and does a solid job, but I have a hard time figuring out what he's done and when he did it, so I look like an ass when I get quizzed on where his pieces are at.
3. Is slow to complete and a talker. Not a bad guy, but he's that dev who wants to challenge design decisions and whiteboard all day instead of coding.

So I'm struggling with an approach that encompasses the different types. I suppose I'm trying to abstract out a personality management framework where acting like a human being might be the smarter approach. That's good to know, so thanks for driving me to that.
posted by yerfatma at 10:34 AM on May 11, 2006

There's a whole big field in regards to Agile development practices (RUP/SCRUM/XP etc) that can help deal with these issues but would probably not be viable options in a short time and require a lot of buy in. One thing that many of these incorporate is the concept of a daily 10-15 min "standup" each day covering:
1. What did you do yesterday.
2. What will you do today.
3. What's blocking you.

Something like this (and it can be daily, every other or weekly, though daily is best) may help you in getting a good handle on what people are doing, tracking progress and in general improve the communication amongst the team.
posted by bitdamaged at 10:50 AM on May 11, 2006

We're actually doing a quick 15 minute meeting every morning to talk about where people are on their current piece. It's gotten me more visibility (yes, I just used that awful bit of management-speak) into what they are working on and where they're hitting walls, but I feel like the communication is still not there. I think my reputation/ personality keeps them from talking as peers (the general feeling being, if I say so, it must be right). But if I don't take the pulling teeth approach, no one sayas anything.
posted by yerfatma at 10:54 AM on May 11, 2006

If you're managing a software development project, you should spend most of your time managing and not coding.

The situation where a manager can safely code is when you are working on a small project and you know the team members very well, both technically and personality-wise. It's easiest when team members are both technically and personally mature/advanced.

This is not something that new design managers feel entirely comfortable with as you pointed out (guilt etc.). There's a cultural bias amongst designers that managers "don't do anything". It's a paradox because smoothly running projects don't tend to notice their managers. Good managers create the conditions where good work happens. There shouldn't be a lot of fireworks happening :-).

If you're having a hard time figuring out what one of the team members has done, it sounds like more management time is needed.

One of the biggest traps (sadly from my own personal experience) is to think of the management component as secondary to the technical work.

One of the most useful books for managing (aside from some of the ones mentioned above) is Peopleware by deMarco and Lister. The other is 13 Fatal Errors Managers Make
posted by storybored at 10:57 AM on May 11, 2006

You are now a manager. It is no longer your job to write code. It is your job to make sure that the code being written by others is the right code at the right time, where 'right' is defined in terms of satisfying the (identified and recorded) project goals and satisfying the required level of quality for those goals. Everything you do, however you do it, must contribute to those goals. It's easy to get distracted. People have written hefty books on this problem and you can even get entire masters-level degrees in it, if you're so inclined, so I'm not going to be more specific - there's lots of resources you can pursue.

However, someone has put you in this position, presumably because they think you can manage it despite knowing you're inexperienced. Remember that your superiors can be as much of a resource as your subordinates. Job one is to make sure you thoroughly understand what their expectations are, of both your performance and the project's outcome, and what you can expect in terms of support and mentorship, if anything. The remainder of your job is to figure out a plan to get there, communicate that plan to your team and follow through to make sure that whatever they are doing fits the plan.

On preview:
You are as green as you sound. But that's ok and it's not your fault. This happens all the time. Many software outfits seem to think that people who have a high level of technical skill and experience will somehow magically be able to translate that into instant skill as a manager without training or support. It's daft, but there it is.

Everyone always remembers the Mythical Man Month idea, which is reasonable given it's the title and Brooks was right, but if you ask me the real gem in that book is No Silver Bullet. The job of a software manager is to concentrate on the essential, not the accidental. Very few software projects fail because of technical incompetence. Knowing the how is the easy part, figuring out what and when is what makes the job interesting.

Some of my problem is getting feedback from the other developers.

This is a big red flag. Deal with it now. Developers have to understand that a big part of their job is communication. Lack of it will destroy a project in no time at all. Rogue developers are the kiss of death, I've seen a $2million project destroyed by kids fresh out of school who think they know best and managers who didn't control them. If someone isn't working toward your goals, you must call them on it and put it right. You have to set and communicate expectations and follow though on them. Know your carrots and sticks and be prepared to use them when you need to.
posted by normy at 11:46 AM on May 11, 2006

Skip the morning meeting- have it weekly. Tell your staff that they must each send you, by the end of every day, a simple status report, covering bitdamaged's points. Just a simple, bullet-pointed list.
posted by mkultra at 11:50 AM on May 11, 2006

Skip the morning meeting- have it weekly

My developer instinct says to do exactly that, but the one thing the meeting does do is remind them they're working together. My fear is that moving to an email will put them back into freelancer mode.
posted by yerfatma at 11:53 AM on May 11, 2006

There's no reason you can't write code and manage. Just don't get your priorities messed up. Manage first, then code. Also, yes, do the daily meetings with each developer. Even if it's only 5 minutes over instant messaging... you'll be able to catch problems and know what's up much quicker. You might follow that up with a more in-depth, hour-long meeting every 2-3 weeks. Finally, you need some sort of notion of a milestone. A time when everybody can come together and see some demonstrable value that's been created. This shouldn't be too far apart--six weeks at most, less if you can pull it off. As for estimation, I'd say don't worry about it. Just focus on reaching the next milestone and making forward progress. Frequent communication and checkpoints will get you through 95% of projects.
posted by nixerman at 12:08 PM on May 11, 2006

Group meetings for the purpose of sharing information SUCKS, whether it's managers or coders. At least 50% of the information is irrelevant to any given person.

If you want the daily emails to remind people they're a team, then make sure everyone is cc'd.

You may underestimate the value of sitting down every day for 15 minutes or so with each coder and (a) asking if they have any questions or problems they want to discuss; (b) asking them questions about their previous daily email when you aren't sure of things; (c) picking one thing that they're doing to review with them ("what's your approach?").

Also, one-to-one, face-to-face feedback is the way to make expectations clear: "Your emails are too brief [or too long]; what I want is something like what X and Y are writing"; "I really like what you did with part Z" or "You seem to be spending a lot of time polishing your work and not moving forward; you're not accomplishing anywhere as much as I think you could."
posted by WestCoaster at 2:39 PM on May 11, 2006

Scrum, baby. Honestly, give it a read and serious consideration. I love it.
posted by trinity8-director at 5:10 PM on May 11, 2006