Skip to content

Category: metrics

warning: Invalid argument supplied for foreach() in /home/artemmarchenko/ on line 1270.


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