Not Everything is the Circus
It was the quintessential Twit-versationTM.
Mike Shaver tweeted a couple of weeks ago “you can make a surprising amount of stuff happen just by making people believe it’ll happen, and that it’ll be fun to make it so.”
I replied—admittedly sarcastically—that he, “clearly [had] never been a build engineer.”
Shaver corrected me, but didn’t address the point I was implying. And then it devolved into a critique of analogies, never again to return to the discussion.
Fin.
Thing is, even though my reply was sarcastic, I really did want to substantively discuss it; it’s a topic I struggle with constantly1.
Let us be honest: the core principles and tasks involved with configuration management often provide a roadblock to software development. Anyone saying otherwise is deluding themselves2.
Learning some new tool, merely to submit code you’ve already written to some magical file-store? That’s annoying. Even having to check in3 puts a speed bump in developers’ cognitive flow.
Monitoring some rainbow-colored waterfall of build information after you check in? More distracting annoyances. Plus, it takes4 time.
Coordinating and documenting changes to the official build environment instead of just making them? “Why do I have to do this?”
And yet, all of these are (just a few of the) bread-and-butter tasks for a well-run build/release organization, and they’re all widely regarded as best practices for modern software development.
Obviously, the friction on developers’ work flows and on development teams themselves created by these activities can be reduced5. But they can never be totally eliminated. And none of those tasks are particularly “fun” for developers.
Just like scrubbing the bathroom toilet isn’t “fun.”
Or chemotherapy: not “fun.”
Getting permits for that remodeling project? Wouldn’t describe that as “fun.”7
Doing the fourth release in two days from the Christmas dinner table: no fun.
But they’re sometimes necessary. And we do them because the alternative is worse.
Unfortunately, motivational-speaker pablum won’t change the fact that they’re necessary, nor address the lack-of-fun involved.
I sincerely would love to get people genuinely excited about Perforce integration procedures or release environment reference specifications or build system tools8, so that developers didn’t think of all of these things as such chores.
I would love it if it were as easy as parroting that these things are fun, but as someone who’s been in this role for almost a decade now9, I can tell you it’s never been that simple. It has always relied more on a combination of pain/risk avoidance, management support, and resource allocation and less on “motivational mantras.”
That was my point.
Of course, to the prospect of finding new mantras to try when “No really, this will be fun!” doesn’t work, I say: I’m all ears.
_______________
1 I had gotten distracted from writing this post, to the point I hadn’t finished it; when I ran into exactly this issue again this week, I decided to…
2 Or trying to sell something
3 Sorry, sorry, “push”
4 “Wastes”
5 Especially when the release teams serving them aren’t resource constrained6
6 A niche I find myself having a knack for randomly continuing to fall into…
7 Turns out: my roommate probably wouldn’t either…
8 Ok, maybe not GNU Autotools
9 And who’s still doing it
bread-and-butter tasks, dear. Motivational-speaker pablum is balm to my eyes. Otherwise, I haven’t a clue what you’re saying.
“Yes, mom; updated, mom.”
You’ve definitely got a point. I think it’s all a case of people being very bad at judging the tradeoffs involved in future planning. Automating your build processes is no fun now, but it’s a hell of a lot better than rolling release candidate 4 by hand on Christmas Eve. Of course, it’s not *you* doing that work, it’s future-you, and screw that guy! (Incidentally, future-me thinks past-me is a dick sometimes.)
@Ted,
Regarding past-me, I agree! Total dick!
I’ve been thinking a lot lately about this sort of stuff.
As I mentioned in footnote 6, I’ve realized the lens I tend to view these things through is often warped by my history of being a member of resource-constrained build/release teams (which is why I’ve said metrics like releases/week (or day) and “wall clock numbers” are pointless grandstanding; if you have two release engineers for every developer, you can get a lot of interesting projects done.)
There’s a fundamental contradiction that I’ve been wrestling to understand, and which I pointed out to Shaver: most technology managers/execs who’ve been in the business any amount of time have seen (or experienced) the friction that brittle build systems, under-powered infrastructure, and resource constrained build teams bring to development teams; one would think there would be a focus on mitigating that with keeping track of the resourcing to ensure it doesn’t get too out of whack at the least; some empathy would be nice, too.
In the end, I suppose I should pride myself on my history of dealing reasonably well in these environments, but they’re more stressful than they need to be (on both release teams and development teams), and they lead to this perception of build teams, I think, as “second class citizens” (this is also experienced with IT/ops teams, I’ve found).
There’s more to say on these points, but I’ll save it for more comprehensive treatment in some posts I’ve been working on about these topics.