Good Grief! Good Goals!

Martin Fowler has an essay on An Appropriate Use of Metrics. It's a useful summary of how metrics are abused and often obscure the true intent of the goals they support. It provides guidance on how to improve goals by placing metrics in a supporting role, instead of a deciding role.

If you've done research on this you've likely heard it all before. I like this essay because it's useful to refer to from time to time and it's broad enough that you can use it to educate others on how to get your metrics aligned with and supportive of the intent behind your goals.

I think it important to emphasize something that Fowler touches on when discussing explicitly linking metrics to goals. He states:

A shift towards a more appropriate use of metrics means management cannot come up with measures in isolation. They must no longer delude themselves into thinking they know the best method for monitoring progress and stop enforcing a measure that may or may not be the most relevant to the goal. Instead management is responsible for ensuring the end goal is always kept in sight, working with the people with the most knowledge of the system to come up with measures that make the most sense to monitor for progress.

Management is responsible for ensuring that the focus remains on the end goal and for working with the people who are best positioned to develop meaning measures of progress.

Absolutely. That means you need to engage.

What's in a Dependency?

In The Right Thing, James Hague discusses the challenges of selecting good libraries to support your application. In James' example it's a Perl module that turns out to be unmaintained and eventually falls victim to a security issue.

I read James' article a couple of times. On the first read, I took it as a comment on the peril of replacing working code with a third-party library. On the second, I took it as a comment on dependencies and over generalization.

I sympathize with James. He doesn't go into detail on his program but it's hard not to rationalize using a library when one is available. There is the problem of replacing working code with a library.

His comments echo concerns in my own product on the introduction of libraries. The product I work on overuses (some say, abuses) an application framework to the detriment of the product. In response, some team members are suggesting other libraries with simpler APIs but supporting similar functionality.

On the surface, adding libraries is reasonable.

What bothers me is that agreement means I have two libraries with similar functionality but different APIs. There differences introduce costs--additional tests, learning curve, different failures modes and security issues. It introduces the question of which library to use going forward.

There is no easy answer. A good answer requires understanding the trade-offs involved.

• I want a consistent product architecture.
• I want to avoid arbitrary complexity. 
• I need to be pragmatic--the pragmatic demands guidelines. For example, replacing the old library with the new one or using the new one whenever it is sufficient for the task at hand.

The change in perspective provided by the second read was profound. I view James' comments as a warning to evaluate dependencies before accepting them. Caveat emptor, if you will.

So what do you look for in your dependencies?

• actively maintained
• recent release
• good platform support
• good reputation within the community
• active user community
• large user community
• meaningful tests 
• documentation

James provides several links to support his article. In one link I was introduced to Huffmanization. I wasn't aware there was a term for making your most common function names meaningfully short.