Advice on leading a software development project

In My Humble Opinion
21

Although some overtime is unavoidable, don’t depend on it to make deadlines. Writing good good requires creativity, and the more hours a programmer works the less creative he is. After a certain point, you’re just going to end up with bad code that has to be rewritten.

Part of a project manager’s role is to deliver bad news to the client when needed; once you know that a deadline isn’t going to be met, tell the client THEN. Don’t dither around and hope coding 100 hours a week will fix it. You’ll never be more of a hero to your team than when they know you took the bullet to extend a deadline.

About deadlines again: There’s only three things you can change in a project to change a deadline: 1) Adding or removing functionality, 2) Moving the deadline, or 3) Adding or removing resources. Adding resources (that is, more programmers), especially late in the project, is the least efficient method for increasing work done because of the ramp-up time required. Throwing bodies at a deadline often makes it worse.

22

The other thing to do with that feedback step is for each person to say what explicit tasks they are taking out of this meeting. So by the end you have a series of commitments like

[Name] will complete [task description] by [date/time].

I used to sit through a lot of meetings where at the end the usual issues had been given an airing and there was some general concensus that choice A was better than B which was just slightly better than C. But nobody ever said “OK, we’re actually going to do A, and so Bob you need to do X and Sam you need to do Y”. Instead we all walked out knowing the concensus was A>>B>C and that was it.

Bottom line: A meeting without a clearly communicated decision & explicit follow-on task assignments is probably a waste of time. And having folks state their own understanding of their assigned tasks improves the odds that the tasks are correctly understood.

23

99% of the time my people come to me with a problem and they already know the solution, they just need someone to take responsibility for the decision. Just listen to them and you’ll usually know what to do.

My rule is: *Always give credit when it is due, always take responsibility, even when it isn’t my fault. *

However, I follow that with, I will not tolerate dead weight. If a person can’t/won’t perform, I will not keep him on my team. This does not mean that the first or second or third mistake will get you fired, it just means you have to be working with the team to finish the job. If someone can’t perform, it does not mean he is a bad person, sometimes people are just in a position that they aren’t suited for. I try hard to either help him be suited, get trained or whatever, or find a place where he can perform. But some people can’t be saved. Try to recognize this and make the hard choices.

When someone gives me a solution that I approve of, I always follow it with an email instructing them to do as we discussed - giving them the comfort of a paper trail. After a while people know I’ll take responsibility, but in the early days a paper trail is comforting.

You will be amazed at how far a little well-deserved praise goes. But do not give empty praise, after a while it becomes cheap.

As others have said: AVOID SCOPE CREEP! Say no. Say in the next phase. Do not put your people in a position to fail because their goals have changed. They will resent you for it.

I love the idea of scrum. I believe strongly with the right team it would be very powerful. I have never seen it implemented well. (Which is not the same thing as saying it can’t be implemented well.)

If you have the misfortune of having a boss who will not respect the management chain, try to teach your people to say something like: That is a great idea, lets call Khadaji in so he can be part of the discussion. This helps keep them from having to agree to something they can’t do, or the awkward situation of having to say no to his boss’ boss. (My old boss, though I love him, would go to my people and add features, because he knew I would say “next phase”. One would tell him to invite me in the discussion, the other would say OK, don’t tell Khadaji. The first was a happy worker, the second was always angry because he had trouble meeting his deadlines.)

24

I’d agree with you in the case of a final deadline, or deadlines for out-of-house customers, but I was referring to the internal deadlines set within a development project. The response to falling a little behind in attaining a goal should be working harder and smarter to make the goal. Take a look at my comments on Agile/Scrum. Hesitation is the enemy of progress.

25

I was addressing meeting effectiveness. Action item status reviews before the meeting and new action item summaries after the meeting are pretty common. Every meeting in Intel works that way, and I’m in a lot of meetings which are pretty much entirely action item reviews. But I’ve also been in lots of ineffective meetings that thoroughly cover this.

26

True, but delays of a quarter happen a day at a time. If things slip slightly, work harder. But also recheck assumptions on programmer productivity and the complexity of the work.

One way of handling scope creep early is to tell whoever it is who needs the new feature to decide what planned features to dump. (Late scope creep is going to screw you no matter.)

PoorYorick’s point three, btw is Brooks’ Law. Anyone planning to run a software project who has not read “The Mythical Man Month” should do so right away.

27

And that’s what it’s really all about. Re-evaluation, re-re-evaluation, and so on. Time frames are just guesses when they’re made. Missed goals are more often the result of misunderestimation and failure to see problems along the way than a lack of productivity. Plan B should be formed at the same time as Plan A. If Plan A starts to slip, implementation of Plan B should begin immediatly, along with the formation of Plan C. It doesn’t mean scrapping Plan A, just rescheduling. The alternate plans keep the project moving by providing a shortcut to a goal that other developers depend on. In the case of a complete failure of Plan A, it may provide nothing more than a platform for the development of a new alternative.

I wanted to follow up on your comment about code reviews also. I can’t think of anything more valuable. It’s the way for everybody to develop their skills, and a second set of eyes catches twice as many problems. Code is like prose, it get’s better with editing.

In a similar vein, documentation is often inadequate. Not the end user manual stuff, the commenting in code. A programmer should be able to understand how code works by reading the comments, and reproduce the functionality of faulty component if it can’t be debugged in reasonable time. The inputs and outputs and dependencies have to be listed, but most important is the description of the algorithm, and the exceptional cases that are dealt with. Programmers have different styles, but I’ve found for myself this is easiest to do as the work goes along, and helps get it done.

28

I’m the owner of all the software that lives on the PC side of the product and the technical leader of the team that will be developing it. I’m responsible for the overall architecture of the software, as well as getting the team ramped up, getting them motivated, and overseeing their activities. I’ll also be coding a few specific parts of the software myself as well. I’m not too worried about handling the technical aspects of the project; while it’s certainly a non-trivial piece of software, and I’m sure we will run into a problem or two, it’s very similar to a lot of the other projects I’ve worked on before. It’s the ‘herding cats’ aspect of the responsibilities that I haven’t got much experience in.

30

sharma - Are you trying to sell software development services in a thread containing the advice garnered from several man-centuries of software development? Just askin’?

31

Things that work well for me (many already mentioned)

  • protect your team from unwanted intrusions - you are there to shield them
  • don’t think of yourself as the apex of the team hierarchy, instead you are the foundation that they rely on
  • involve your team in decision making, don’t think of yourself making decisions but instead, of insuring that the team as a whole makes good decisions
  • your team is smarter than you are
  • realize that at least one of your programmers will be 5 or even 10 times more productive than the others - make use of that person as a mentor when you can
  • have daily 5 minute, standup hallway meetings instead of long weekly ones
  • have team members pair up to do a code review before checkins to the source management library (you do have one, right?)
  • testing is an ongoing process - all through development - testing and quality is not ‘bolted’ on at the end of the project.
  • if you have the luxury of also being a working manager, take the least desirable tasks.
  • don’t force a methodology without team buy-in