Don’t use anything fancy like Microsoft Project. The trouble with Microsoft Project is that it assumes that you want to spend a lot of time worrying about dependencies….I’ve found that with software, the dependencies are so obvious that it’s just not worth the effort to formally keep track of them.

– Joel Spolsky, Painless Software Schedules

That article has many other great insights, including:

If you are sloppy, and pick big “chunky” tasks (”implement grammar correction”), then you haven’t really thought about what you are going to do. And when you haven’t thought about what you’re going to do, you just can’t know how long it will take.

…and

Many rookie software managers think that they can “motivate” their programmers to work faster by giving them nice, “tight” (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I’m behind schedule, I feel doomed and depressed and unmotivated. When I’m working ahead of schedule, I’m cheerful and productive. The schedule is not the place to play psychological games.

As the article is over ten years old, Joel has end-of-lifed it, and replaced it with this one from 2007. I still like the original!

Photo: “Brian’s Classroom Support calendar” by StanfordEdTech

Other programmers are happy to question the spec, to discover business functionality that may not have been known, and to engage more in design.

Sometimes, and ideally, these functions are separated; you have a programmer who solves problems made clear in the spec, and you have a software project manager/domain expert who designs the solution to be implemented by a programmer.

Having said that, it’s not unusual to find the two functions in a single person, particularly a developer with more experience within the problem domain (in fact, it’s hard to find a project manager who’s experienced enough to design a good solution, who isn’t an experienced programmer).

Standard project management technique would suggest you start with the scoping, and the environment (the “why” and the “what”), and only when you get to identifying the work, to get down to the “how”.

Frequently, the guys involved in organising the scope are not the guys doing the actual nitty-gritty work, so by the time they’re involved, the “why” and “what” should ideally have been specced out.

With software development, particularly with iterative methods, the “what” is usually figured out as part of each iteration, which lets the “why” leak in, and should ideally involve lots of two-way communication between the developers and the client.

This isn’t always how it works though. As I said above, it’s an ideal world that can separate the functions, and often a programmer with enough experience to connect business analysis with programming will already be filling that role in any given project.