Metrics like complexity and lines of code are easy to measure but can be gamed, and don't capture important quality aspects like naming conventions. While managers want measurable objectives and results, such metrics don't provide useful insights and may incentivize the wrong behaviors. Developers complain that measurable things are not necessarily the things that should be used to manage software quality.

1. @meekrosoft
METRICIDE

2. (The curious consequences of counting)

3. The Manager Said
• That No Manager Should:
– Sit on his hands and
– Expect software be good

4. The Problem you see..
• Is I haven’t the time to:
– Read all the code
– Line after line

5. But I Measure!
• Complexity
• And lines of Code
The proofs in the numbers
(or so I’m told)

6. Things like complexity
• Are:
Easy to explain

7. Things like complexity
• Are:
Easy to explain
Easy to measure

8. Things like complexity
• Are:
Easy to explain
Easy to measure
And easy to game

9. WHEN MY MANAGERS
MANAGER TALK OF
TIMEFRAMES
I CAN SAY WE HAVE BIGGER
PROBLEMS TO TAME.

10. NOT
• A solution
• A direction
• A vision
• Insight

11. “If you can’t measure it you cant
manage it”
• The Managers Delight:
Magic

12. “I want an objective for coverage degree. Results
I can measure. Results I can see.”

13. “I want an objective for coverage degree. Results
I can measure. Results I can see.”
“We might just make it!”,
they said with glee

14. “90 percent coverage!”*

15. “90 percent coverage!”*
*(assertion free)

16. • Developers complain (like they always do)
– Things we can measure are not things we should
use
• Coupling, cohesion
– help like they should

17. BUT WHERE IS THE METRIC FOR:

18. BUT WHERE IS THE METRIC FOR:
“Naming things good”?

19. BUT WHERE IS THE METRIC FOR:
“Naming things good”?
(Thank you)