The Many Shades of “Fixed”
One of the software shops I was working with kept using this phrase I’d never heard: “done-done.”
Its most common use was in the context of whether the work for an agile iteration was completed, more… well… “done than merely “done.”1
During my day long session with Agile trainer extraordinaire Kenny Rubin, I finally got the story behind this term’s genesis:
My twelve year old son was working on his math homework; like many kids, math isn’t a subject he’s entirely enthralled with. When I saw him playing outside, I asked “Is your homework done?”
He responded it was, so I went to take a look.
It wasn’t.
I later asked him why he said it was done when he, in fact, was not finished. During the course of the conversation, I realized our definitions of “done” were different: to him, “done” meant “I did all the problems I felt were necessary to illustrate that I understand the concepts.” To me—and, of course, his teacher—done meant… well… y’know… done.
To avoid future confusion, we agreed that “done-done” would mean that he had actually finished the entire assignment. These days, on his way out the door to play, he’s proudly reports that his homework is, in fact, done-done… usually.
(At this point, everyone giggled at how this term we’d been using day in and day out came to be.)
In thinking about the “done-done” concept more, I realized it’s a very useful distinction to make, and being able to come up with specific phraseology to improve and standardize communication was great!
I also realized the release engineering-focused work I was doing had a similar concept, but “done-done” didn’t quite fit: for one, a lot of our projects did not (and weren’t intended to) fit along agile’s iteration boundaries; being a service team, many of the things we worked on were interrupt-driven, and in fact would never be “done” or “done-done.”
While dealing with the monthly “official builds CIFS share filling up”-event, our version of “done-done” came to me: is the problem fixed? Or is it “fix-fixed?”
Many operational teams “fix” problems: shuffle the build deliverables to a another drive IT set up, or fix the unit test that’s broken on that specific continuous integration slave by installing the missing library.
But they’re not addressing the fundamental issues: capacity planning for the release engineering infrastructure, or the lack of configuration management.
In short, they’re not “fix-fixing” any of the problems.
There are a lot of reasons this is detrimental to a release engineering team2, but the most obvious business reason is the inefficiency. In the worst cases, this can be observed by unpredictable, arbitrarily-long product release processes, because the environment where those are taking place is built upon a house of cards, which may requiring “fixing” at any point.
Of course, this doesn’t mean an issue can always be addressed by “fix-fixing” it at exactly that point; if that official build share is full, the primary goal is likely getting builds cleaned up, as it should be. But when one can reliably set their clock by the monthly Build Share Drive Is Full Day, it’s clear that no long-term solution: the issue isn’t being fix-fixed.
The price of an environment that doesn’t value3 “fix-fixing” issues is very apparent if you know what to look for, and the cost is huge4,5
These days, I’ve realized making apparent the distinction between “fixed” and “fixed-fixed” is critical. I make it a point to ask the (IT/TechOps) teams supporting us whether they’ve fixed a problem, or fix-fixed it.
In turn, I make it clear to those around and above me whether we’ve whack-a-moled their issue… or actually addressed it, so it won’t come up again.
And if they’ve never heard of “fix-fixed,” my answer always starts with “Now that’s a fun story…”6
_______________
1 A whole 100% more done, in fact…
2 Team morale being a notable one
3 Or, in some cases, isn’t given the bandwidth to execute
4 I’d argue unpredictably so
5 Though, like a bad game of Telephone, the burdens are often disconnected from the event, so it’s easy to dissociate them from this problem
6 Followed by “Have you heard of a guy named Kenny Rubin?”
I like the footnotes, but could you wrap them with an abbr html tag? Then people wouldn’t have to click or scroll to read them.
Thanks.
@Dean:
I’ve been doing the footnotes so long, I don’t believe the <abbr> tag was consistently implemented when I started this blog. I do remember trying to use it, and some browsers would only display the first 100 characters or so; sometimes, my footnotes are longer.
I actually have a tool that generates the footnotes, so I’ll look into what it would take to modify it so there can be <abbr>s and links; though, I’m not 100% sure where I’d put the link for the <abbr>
One of my clients had a CEO named Evelyn. She was really good at holding people’s feet to the fire and making sure things were “done-done”. In fact, she was so good at it that they didn’t even use the phrase “done-done”. Instead they called it “Evelyn done”
I know all about the done-done trick. At a former software engineering position, the expression was “done, but not finished.” Talk about double-speak!