Software Development Team Issues

[KenR]

Here are some nice blog essays on small software team management. See if you agree with them.

Building a software team: Wrong! There I said it!
The development team that I managed the longest -- the one with the Gumby -- was a typical bunch: a group of people with varying strengths, interests and personalities. In different combinations they mostly liked, sometimes loved and occasionally hated each other. And after a couple of reasonably successful projects, I led them off a cliff.
I committed them to a schedule they could not keep, based on a technology that did not work. I made the call and it was wrong.

http://jroller.com/page/rolsen

[f0dder]

Nice short blog entry. And he's right - admit it when you're wrong. Won't always work out to your advantage, but at least you've got your integrity...

[tinjaw]

Nice short article. I find that the best thing to so is remember that some things can be estimated based on past experience and some things are just guesses because they are mostly new. And one should be held to varying degrees of responsibility based on these factors. With this slightly more expanded picture you can then differentiate between what you are expected to hit very close to dead on and what you are unsure about. And when the overall goal is missed you should be able to show that you hit your marks on the former and missed on the latter. It is one thing to screw up royally when you are doing something new, it is another when you screw up on something you have done before and should have know better.

So yes, I agree completely that you should fess up to your mistakes, you should put things in perspective.

UPDATE: I forgot to mention that one of the reasons you should differentiate is that you want to be able to show that your team learns and adapts and gets better over time. Hence, you want to show that your estimates based on past experience are much more accurate. I help put things in perspective and keeps team moral up. In other words, don't slink around the fact that you screwed up overall, but don't overly focus on the mistakes.

[mouser]

The idea that it's good to fess up to your mistakes is an important, but easy lesson to learn.

A harder lesson is equally important:
Don't make extravagent promises that you can do something in X days, and hope that if "everything goes perfectly" you can meet that deadline.  Most programmers I know, including myself, tend to grossly underestimate how long something will take, and nothing every goes perfectly.

[tinjaw]

Heck, I constantly underestimate the simplest of tasks. I can't even estimate how long it will take me to get out of bed from the time my alarm goes off in the morning.