Software development coach and speaker.
Legacy code wrestler.
Award-winning bad poet.
Agile in 3 Minutes podcaster.
☕ Buy me a fancy coffee
Comments in the moderation queue:
Recently posted comments:
A friend Jay Packlick has done a few talks and presentations around this concept - Metrics that Matter
He has suggested that we plot the metric on a grid - Y axis - Potential for Value and X axis - Potential for Evil. When I started doing this… it became much clearer when to say no to a metric and when to say… well OK, as long as we keep this idea true… and circle the area on the grid that we discussed.
I’m wanting to +1 your whole rant, I’d like to nail it to the front doors, I’m thinking about a tattoo, but unsure where on my bosses body it should go…
I have sometimes fantasied about asking the VP that want’s a new metric, if it would be good for us to add one that measured their leadership of our group - I’ll call this metric Mean Time between Disruptions (MTD). MTD is calculated much like the old factory sign that said “its been 23 days since we killed someone at this factory”. So let’s start counting (I suggest in weeks) the time between a major disruption to the team. For this basic metric we are looking at basic team formation dynamics (your familiar with Tuckman’s Forming, Storming, Norming, Performing) and you mr. VP want the P word - but it comes after 3 stages of development beyond the F word) So let’s start at the beginning and count weeks between Forming and ReForming. You know like when you move a person on/off a team. When you move the team’s physical location, when you give the team a new objective.
The metrics I’ve seen range from MTD = 0 - 20 weeks for many teams I’ve worked with. And they say they desire persistent teams.
Long ago in my career when I was doing large waterfall projects — 9, 12, 18 month release projects — we had to measure things or we couldn’t tell whether the project was in line with successful delivery, for whatever definition of “successful” we were working under. I have a whole list of metrics I’ve kept. They were mostly useful. And I did use the same organizing principle you mention: I didn’t measure a thing unless there was some concrete decision we would make with the result.
The great thing about the ways most places deliver software today is that we’ve broken things down into small chunks where you can usually tell just by some version of “looking at it” whether things are going well or not. And I never, ever want to go back to the old way. Because every last thing I measured ended up gaming the system. People naturally want the things they’re being measured on to turn out well for them. I even tried to measure without the teams knowing what I was measuring, and it still ended up influencing behavior.
I think your question, “What decisions will this metric help you make?” is the right one to ask, regardless of whether its motivation is gut-level resistance. It challenges the person wanting to put the metric in place to truly think through what they’re trying to accomplish. If they can get to the root of what they want, very often you can have a meaningful and productive discussion with them about that.
I was about to share a link to an MP3 from an old
and was reminded that with ikiwiki I’m free to move podcast attachments from old
locations (/file_download/16/foo.mp3) to sensible spots (/year/month/date/post-title/foo.mp3, right next to its show notes).
With a few shell pipelines, I moved the files, updated references to them, and generated Lighttpd redirects so old links keep working.
Then I shared the nice-looking link to that MP3, and observed the utter absence of a top-level file_download directory in my repo, and was happy.
Oh yeah, this site has finally joined the modern era. Not only SSL, but also no more www. in front. Old URLs still work, of course! This required no change to the site’s Lighttpd config, just a simple-enough-to-guess-right change in the host’s Pound config.
BTW, a very handy way to manually check redirects is curl -I -L "http://www.old.url/that/should/get/redirected".
curl -I -L "http://www.old.url/that/should/get/redirected"
When I ported this site from Apache
some of the configuration could only be expressed using
Now I’ve got a few months of log data. The Lua script was being called for exactly two redirects of nonzero value (7 hits each, not counting bots). So I’ve turned mod_magnet off, gzipped the script for reference, and added these lines to the site config:
# [Feeds + Non-feeds] rewrite uppercase "tags" that had been Textpattern "categories"
"^/tag/Assignments(.*)" => "/tag/assignments$1",
"^/tag/Music(.*)" => "/tag/music$1",