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