Comments in the moderation queue: 0

Recently posted comments:

Not this time around, but my folks are still in the northern suburbs, so I get back there from time to time. Will let you know next time that happens!
Comment by Amitai Schleier Thu Mar 23 12:45:29 2017
What, no Chicago love?
Comment by Dave Schinkel Thu Mar 23 04:57:30 2017

A friend Jay Packlick has done a few talks and presentations around this concept - Metrics that Matter

https://speakerdeck.com/improving/visualizing-agility-agile-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.

Comment by David Thu Dec 22 17:39:39 2016

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.

Comment by David Koontz Thu Dec 22 12:03:54 2016

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.

Comment by Jim Grey Thu Dec 22 10:00:41 2016
Posting comments here is too difficult, especially from a phone
Comment by Me again Thu Dec 22 00:01:50 2016
If you’re in an environment that’s going to demand bad metrics, just accept that and mitigate it by picking and instituting metrics you can live with before anybody even asks for one. It’s easier to negotiate from that position.
Comment by Nathan Arthur Thu Dec 22 00:00:30 2016

I was about to share a link to an MP3 from an old Schmonzcast, and was reminded that with ikiwiki I’m free to move podcast attachments from old Textpattern-mandated 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. :-D

Comment by Amitai Schleier Wed Nov 16 22:45:59 2016

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".

Comment by Amitai Schleier Tue Nov 15 13:32:00 2016

When I ported this site from Apache to Lighttpd, some of the configuration could only be expressed using mod_magnet and a Lua script.

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",
Comment by Amitai Schleier Tue Nov 15 13:21:26 2016