Coffeehouse Thread

3 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Team Performance Review Question

Back to Forum: Coffeehouse
  • User profile image
    Sathyaish Chakravarthy

    Do you use any scientific basis to come up with mathematically accurate metrics for determining the performances of the individual members in your team? Is there a system of productivity measurement for software development teams that yeilds meticulous results?

    I am reading this book called Practical Software Measurement by Bob Hughes, and feeling like someone's hitting my head with a block of wood all the time.

    The advise is poles apart from all the common sense advise people like Joel and myself for my own thinking, have on software development.

    In the book, there's a productivity metrics factor given as the quotient of the size of the project in SLOC as the divided and the effort in staff-days as the divisor.

    The problem I see with his approach is:

    (1) Project size (SLOC): How would you arrive at an SLOC of something that has not yet begun? You could refer past project experience, like all books say, but I see fatal flaws in that.

    (2) Past projects reflect past environments. They are dependant on historical factors such as the organization culture, the management of the project, the skill of the people who were involved in the project, the language that was chosen for the project, the skill level of the people with that language, the cyclomatic complexity of the project. A 12,000 SLOC business application would have taken 12 weeks, but a 12,000 SLOC compiler would probably take more than a year and a half to develop. Or for that matter a real-time or embedded system would take longer. You cannot apply historical data without factoring for the changes.

    There's something that happens in your head when you are a programmer for a long time. That thing doesn't happen in the heads of these authors and management types.

    I am confused. Why do these books have things that do not apply in the real world. Real world is unpredictable, subjective and intuitive.

  • User profile image

    Where I'm at, we have performance reviews, but they're mainly show. The criteria I use comes from just general day to day interaction with my engineers. There is no scientific backing, but more often than not, I'm dead on. If you wait until the very end to figure out how well someone is doing, your number will rushed and riddled with errors.

    It's up to a good manager to figure out if his people can do more. Which leads to a delicate balance of macro vs. micro managing. I prefer he former. I will set milestone dates and deliverables that are very lofty (however, I never ask my guys to do anything I wouldn't/can't). Then we see how it goes. If the milestone is met, excellent, push harder next time. If it's not, I always build in some wiggle room. At that point I can figure out why it went wrong. Mostly, my goals are very progressive, and if we miss a milestone and it's my fault, I can't blame my underlings.

    However, if they just get lazy (which you should be able to tell if you interact with them regularly), then it's time for some motivation. One of the tools we use is a short meeting every morning. We go around, say what we were working on yesterday, and what we are doing today. This gives everyone a chance to see how it all fits and can offer advice if they have lots of previous experience in a coworker's project type (network protocols, database access, predicting weather/wind changes, etc...).

    There really is no good way to attach a number to productivity. Most of our development cycle is spent in design, so the SLOC method is out. You can't use the number of design doc's produced, becuase most of them are index cards, pictures of white board drawings, wiki, etc... Also, like you mentioned, project difficulty plays a huge role. Designing a missile guidance system takes a lot more time and effort for the same amount of code then a business app.

    All it boils down to for me is getting to know your people. Spotting the diamond in the rough is difficult, but with a good outline of your project and its goals, it shouldn't be too hard if you *KNOW* your people. Assigning a number to it is completely useless, yet it makes my superiors happy, so I go with what I feel that my employees should get.

  • User profile image

    Sathyaish Chakravarthy wrote:
    I am confused. Why do these books have things that do not apply in the real world. Real world is unpredictable, subjective and intuitive.

    If people keep all these factors in mind, they cannot write any book. Not all subjects books will be valid always.

    Today by keeping certain factors in mind people will write book, tomarrow those will become invalid. But, if they dont write book at all, we will not learn stuffs which is required in current situation.

    Yash K.S

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.