Agile Otter Blog

In the last installment , we talked about reasons that velocity goes up without any more accomplishment by the team. This is a disturbing occurrence to many managers who want to use velocity as a measure of productivity, and their insistence on treating low velocity as a productivity measure. We'll pick up the conversation from there. A: I don't  like  the "estimating in larger numbers" explanation. What is an alternative explanation? B: Perhaps they've developed skills, knowledge, and/or techniques that make it easier to get more work done. There are a few ways of measuring efficiency. One of the least useful is output over time. If one team of people produce more in a week than another, isn't the one more efficient? It's not possible to say. They may put out a disproportionate amount of effort in order to get a higher yield. That could be arguably more productive  but it is not more efficient . If it's harder to get more work done, then yo...

I saw this in a python tutorial today: if os.path.exists("/tmp/uPlayer"): f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close else: os.mkdir("/tmp/uPlayer") f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close Really, now? We start by duplicating the whole open/write thing in order to create a directory? Maybe one of the problems people have with clean coding is that their examples are poor. If you write, it behooves you to write refrigerator code. Not to mention that close is a function, so it needs parentheses. This code doesn't even do what it thinks it is doing. It's closing the file when f goes out of scope, not when we reference the f.close bound method. It makes me sad for the children.