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
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.
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.
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?”