Skip to content

Category: metricsSyndicate content


August 25, 2008 by Jeremy Weiskotten

Productivity is often confused with velocity. They're related, but they're very different things.

Velocity is the amount of work that you/your team can do in an iteration. In economics terms, productivity is defined as "the ratio of what is produced to what is required to produce" (source: Wikipedia). So, a person who can carve ten statues out of a lump of granite is more productive than a person who can only carve eight statues out of an equal size lump of granite.

At this point it's understood that we can't measure productivity when it comes to building software because there's no good, consistent, accurate way to measure output.

However, while we can't measure our productivity, we can often improve it. Without measurement we won't know how much of an improvement we've gained (or how much we've regressed), but we can measure improvements in velocity, which can indicate corresponding productivity improvements.

The testability metrics

January 23, 2007 by Artem

Most of the agile software development methods explicitly or implicitly recommend the use of test-driven-development and generally development of the testable code. The reasons for the high testability demands are no secret. By the very definition of "agility", the agile project has to be ready and even embrace requirement and corresponding architecture changes. Every hardware engineer knows that it is easy to redesign the wired board only if all the components used are reliable and conform to the own specification. It holds true for the software world - it is easy to redesign the system only if its components are well tested.

There is little doubt that the code testability is a good thing, but how can you measure it? Is it possible to have a look at too classes and tell which one is more testable, than another? How to decide that the component is testable enough and doesn't need the further refactoring?

Score-based metric
Jay Flower proposed a score-based metric for testability.

Measuring time at work

December 14, 2006 by Artem

One of the simplest metrics that some managers are actually paying attention to is time at work, i.e. how much time or overtime each programmer spends in front of his workstation. This simplest metric might work for manufacturing-like tasks: when worker spends 50% more time at the production line, he is likely to produce 50% more goods (those typically he wouldn't be happy about it). However, the "more time – more goods" approach doesn't work for complex, intellectually intensive tasks like programming. Everyday every software developer has to write the code that never existed before. It is not just pushing the same buttons as yesterday; a programmer has to literally invent a new thing everyday. And invention needs a fresh mind.

Best of