“And off our left wing, the Grand Canyon!”
Has it really been over three months since I said I’d provide “more information for y’all when we reach our cruising altitude…”
Time, it does fly.
Astute stalkers observers may have noticed my LinkedIn profile a few weeks ago: I’m now a Principal Release Engineer in Symantec’s Data Loss Prevention division.1
It may seem like a large shift for someone coming from a sub-20 person startup or an environment like Mozilla, both of whom are focused on short release-cycle, consumer software products. And in some ways, it is a huge change: DLP is very much an “enterprisey product” with the associated long release cycles (and even longer support cycles).
What I’ve found really interesting as I’ve come up to speed is how my new team has been moving itself toward a “lean,” agile organization, just like Songbird is and Mozilla is becoming. The requirements, size, and final products are very different, but the path all three take to ship have striking similarities.
It’s also been nice to step back into designing solutions for enterprise release engineering requirements; it was often a hard sell to get resourcing for certain aspects when “the next big release” was two or three months away. But when you have to support a version for three or four years, those conversations tend to go much more quickly. It reminds me a lot of life back in my VMware days, which perhaps also has to do with the fact that I’m on a release team again, which is something I didn’t realize how much I missed and am ecstatic about2. Plus, I get to use Perforce again3.
Of course, as with anything change, there’s been some amount of “Y U NO WORK?!“, but the change in technology stacks—an interesting mix of native C++ on multiple platforms and multi-platform Java-based server components4—has me looking at new things that I haven’t worked with since college. In software, a change of scenery is pretty much always a good thing.
DLP is one of those technologies that churns away quietly in the background, keeping credit card numbers and mothers’ maiden names safe. It does so day in, day out, 24 hours a day, 7 days a week, 365 days a year. It’s not the sexiest of technologies and you can’t script it with Coffeescript. Most people aren’t even aware it exists, but they’d feel the effects if it didn’t.
Not unlike, perhaps ironically, good release engineering teams, infrastructure, and processes.
_______________
1 Some may also know this division by its pre-acquisition name, “Vontu”
2 Someone whose job it is to also know how to run an official build?! YES PLZ!
3 Which, despite what certain ex-VMware coworkers think, I really did miss
4 Amusingly, I saw a copy of the Gecko SDK kicking around in the source tree the other day…
But you were on a release team at Songbird – you and the rock worked well together, with occasional part-time contribution from various bottles of scotch.
Come to think of it, where did that rock come from? All I remember was that it was at 585 (upgrade rock!) and was still around when I left, I think…
@Mook,
I’ve said this before, but Songbird really was one of the first teams where it seemed like the general culture valued all parts of the process.
You were an instrumental part of that, as were other Birders. I’ve been in the position before of having to clean up messes that developers don’t really care about (because it doesn’t affect them, but it does affect the release process and/or build process), and it totally sucks.
That seldom, if ever, happened at with you guys, and I really cherish that about my time at Songbird.
Pretty sure it was just because Songbird was too dang small for that to work – a few us have been there before there was a proper build engineer, or a QA group. It sucked :p
Sadly, I’ve never used perforce. I suspect part of it is because it lacks the killer feature of being free. I’m a cheapass who still isn’t paying for a domain name, or a server, or… well you get the idea. That was a big reason I started poking git at Songbird – I could just drop it quickly if it turns out it didn’t fit my uses and not affect anybody else. I really only needed a glorified quilt, anyway.
Yeah… but oddly enough, I’ve been in environments where that’s been the case (i.e. people were around before there was build or QA), and they’re still zero empathy about it.
That sucks too. (Those tend to be environments where arrogance generally runs rampant and that’s somehow seen as a healthy cultural trait… which I tend to disagree with.)
Re: Perforce: interestingly enough, it actually is free for a single user; it’s also free for open source projects, though I don’t know of any project that actually uses it (I think most projects have a bad taste in their mouth from the BitKeeper debacle (even though from what I’ve seen, Christopher Seiwald is pretty much nothing like Larry McVoy).
For better or worse, I think using anything by git or hg in an open source project these days is pretty much a non-starter… even if it’s the wrong solution for that particular project and its participants. But, as I’ve said before, it’s also mostly-not-worth discussing these days, since the general response to using anything other than git is “you’re mentally retarded” (Linus) or “You need to seek professional help” (Joel Spolsky)*, etc., which is pretty much the definition of an irrational (and thus counterproductive) discourse.
*I actually didn’t go dig up the quotations these gents have made about DVCS; I’ll probably do that for a blog post about this at one point, which I’ve been meaning to do for… y’know… years.