A dependency is when you have two tasks, one of which must be completed before the next one can begin. 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.

Usually, I like what joel writes. Not 'cause i agree or disagree, but because he usually thinks things out.

I've also been known to be proven wrong.

Why to use MS project or something that has equivalent functionality.

• Dependencies are dependencies. They are on resources, which are time and people. You can't make them vanish.
• Tracking them are of the utmost importance. For instance, take a simple junior-senior level programming relationship. One may do the architecture and API type functionality. The second, may do more interface programming and code maintenance. Yes, the dependencies are more obvious, but when it gets beyond these two people, what happens then? How do you keep track of who can do what?
• Time is a resource. When people take vacations and what not, you must make good estimates. Even if you don't factor in the warm-up time after a vacation, you are better off than if you never counted it in. You have things like holidays as well to worry about. What if one of your team-mates is jewish, and needs to take other holidays? It's a pain in the ass to do in excel. Especially when you wish to tell QA something will be ready, and your deployment team as well.
• Time estimates are hard to do when you don't do them often enough. I know in an ideal time situation, it will usually take me n*3 to complete something. If something is really hard, n*5. Good software schedule management programs will take estimates and remember how on track you usually are.

While it may be a little more complex than excel, learning how to use the tools, especially when it's not just one developer doing something and nothing else, it becomes invaluable.

Sorry Joel, but you are wrong.