ROFL – this is to good not to share on a Friday. Enjoy.

The secret driven-development/design acronyms

After a recent trip to my family’s house, my wife and son came down with a stomach flu. Catching the flu is something you really can’t avoid via a healthy life style, but it did remind me of this quote:

Those who think they have no time for bodily exercise will sooner or later have to find time for illness – Edward Stanely

In short, remember to make time to “exercise”. Apply the metaphor however you wish; physical exercise, quality controls such as unit testing, or the act of continuous learning, just remember to do something at least every other day that challenges you to new heights.

While in the midst of other developers, I often find myself in funny little debates about metric analysis. Which metric values determine complexity, which determine quality, and most importantly which of these values are “correct”.

A common target of these debates is Code Coverage Percentages (case in point – Is Code Coverage Really All That Useful). Some argue that 100% code coverage must be maintained, others argue that there is low ROI in maintaining that level of testing.

However in the end, regardless of metric and regardless of it’s value – what matters most is that metrics relation to your satisfaction. In other words, a metric value is only as valuable as the relational context and environment in which it is applied.

Alright, I still feel that definition is a little to wordy, so let me explain with an analogy…

It has been scientifically proven numerous times that people are happier when they are relatively wealthier than their neighbors, rather than just being wealthy. In short, a upper middle class family surrounded by middle class families is more content with their monetary status than the poorest man living on Billionare’s Avenue. Hard to imagine I know…

Metric analysis needs to be perceived in the same way. There is no “correct” value of Code Coverage Percent (nor any other metric) because it is all relative to your team and previous metric goals. For example, a team just learning to unit test might find it a great achievement to hit 70% code coverage results, a venerated team might find shame in not achieving 100%, while another team’s goals might be transfixed on ROI and call 90% “good enough”. All of these metric goals are perfectly correct in their own ways because they are directly proportional to the teams attempting to achieve them.

Just remember the fundamental reason why you started caring about the metrics in the first place, so that you can drive yourself to become healthier, wealthier, and wiser each and every day. Focus on that and before you know it you will be the richest kid on the block.