Slashdot Mirror
Slashdot Asks: How Do You Know a Developer is Doing a Good Job?
An anonymous reader writes: One of the easiest ways to evaluate a developer is keeping a tab on the amount of value they provide to a business. But the problem with this approach is that the nature of software development does not make it easy to measure the value a single developer brings. Some managers are aware of this, and they look at the number of lines of code a developer has written. The fewer, the better, many believe. I recently came across this in a blog post, "If you paid your developers per line of code, you would reward the inefficient developers. An analogy to this is writing essays, novels, blog posts, etc. Would you judge a writer solely on the number of words written? Probably not. There are a minimum number of words needed to get a complex point across, but those points get lost when a writer clutters their work with useless sentences. So the lines of code metric doesn't work. The notion of a quantifiable metric for evaluating developers is still attractive though. Some may argue that creating many code branches is the mark of a great developer. Yet I once worked with a developer who would create code branches to hide the fact that he wasn't very productive." Good point. But then, what other options do we have?
Wow. Those guys were doing Scrum completely wrong. A daily standup is intentionally a "standup" because about the time you get tired of standing means the meeting should be long over. A daily standup should be down to about 10 minutes. If it takes longer, your team is either too larger for Scrum, or people are talking about stuff that should be taken offline. So when someone mentions a block, you don't try to fix it or squabble about it, the Scrummaster (yeah, I hate the term) makes a note of it, and you move on. And when the PM tries to fix the problem, it's the scrummaster's job to cut him off immediately. That's why the SM and the PM are two different people.