Getting to CD In An Org Predisposed To Hate It

I thought this presentation by Dan McKinley was really interesting and resonated heavily with my experience in helping to shepherd an organization that was pendulum swinging from everybody hacking production, to nobody getting to do releases until you filled out a form in triplicate, to an org that was doing 8–10 releases on most days.

We never got to continuous delivery (CD), for a bunch of reasons, but mostly:

  • Cultural (it scares the crap out of the systems and support teams, even if it might be better for them)
  • Technical (it requires good tests and good dev/beta systems, and we’ve always been underinvested in the resources to help there)
  • Organizational (we’ve rarely settled into a structure that allowed our teams to develop the discipline)

But we did continually get better, and I’m guessing in another year or so, with the right people pushing, I don’t think a real CI (continuous integration)/CD pipeline is unreachable.

Some bits from the presentation that were particularly resonant with me …

Namely, we had a lot of process that was prophylactic. It was built with the intent of finding production problems before product

As your organization gets bigger (and not even, like, really big, but just bigger), there are lots of people who think their job is to protect the production org by creating all sorts of process to make it really hard to get something to production. In reality, all that process just makes people pay less attention, not more attention. There’s always somebody else who is more responsible for the code going live, being tested, being right. The further away you are from being on the hook, it’s natural that you pay less attention.

Which is why, smaller, more frequent releases, with less friction and less overhead, makes a lot of sense. It’s your responsibility to make sure you don’t break production, and if you’re going to be responsible, don’t you want to make smaller bets? That leads to this tenet …

Deploying code in smaller and smaller pieces is another way. In abstract, every single line of code you deploy has some probability of breaking the site. So if you deploy a lot of lines of code at once, you’re just going break the site.

And you stand a better chance of inspecting code for correctness the less of it there is.

There’s a lot of goodness in this presentation, resulting from the scars of helping to drag an engineering team into something that works, that has buy in, and increases the velocity and performance of the team (and helps keep everybody happy because they’re working on stuff that actually gets to production). There’s some bits towards the end of the presentation that make sense for one big team, but less sense for multiple teams. Multiple teams is a huge way to help solve this problem. If you can break up your application into smaller, separate applications, or services, or microservices, or trendy term du jour, then you can reduce your dependencies between teams.

That lets each team reduce it’s risk and some teams can ship 50 times a day, and some 10, and some 2. It increases a bit of coordination between teams, but with good documentation and smart API design (ideally with good versioning so that team releases don’t have to be coupled), you can get to a point where teams can all be really efficient and not beholden to the slowest of teams.

Anyway, it’s a long presentation, but I think it’s a really great, real world example of how to get a big challenging org into CD (or at least on the path to it).

Making RSS More Readable

The JSON Feed format is a pragmatic syndication format, like RSS and Atom, but with one big difference: it’s JSON instead of XML.

For most developers, JSON is far easier to read and write than XML. Developers may groan at picking up an XML parser, but decoding JSON is often just a single line of code.

This is such a good, simple idea. In general, I hate dealing with XML (I actively bias against SOAP interfaces too). JSON isn’t more verbose than XML, but is decidedly easier to read, and far less fragile. I’ve added JSON feed to this very site.

“The Miracle on Dirt”

Really loved this little documentary on Virginia Tech softball’s no hitter over Team USA. Amazing numbers from that article:

It was the American team’s first loss in a pre-Olympic exhibition since May 3, 1996. During that span, the U.S. team outscored opponents 1,475–24.

Angela Tincher is one of VT’s greatest athletes (and she should have been pitching for Team USA …). I remember following the team intensely that season.


Random things that have been collecting in my brain the last few weeks:

  • The last time I headed abroad, I realized AT&T had finally caught up to the competition and offered a reasonable international plan (use your data, $10/day).
  • I also realized I didn’t want to waste my data on stupid things I could wait to pull over wifi, so I made it so a bunch of apps could only update over wifi (most notably, Facebook). A couple of months later, when only using Facebook over wifi, and only using it sparingly (I’m ready to be done with Facebook), I noticed I’m using about half as much cell data as I was before. Thanks, Facebook, for preloading all your shit content, and for your huge app updates.[1]
  • I traded in my hybrid for an electric Chevy Bolt. It’s been a pretty interesting experience (more on that in the future), but I did find one odd bug: plug in your iPhone (after using Carplay) before the car is turned on, and it doesn’t seem to be able to boot the Infotainment system. Unplug the phone, and life is back to normal (and then Carplay is usable again when you plug it back in).
  • I’ve enjoyed listening to Crimetown, one of Gimlet’s many podcasts, but their production schedule just destroys my ability to remember what’s going on. Same goes for StartUp. Anything that’s sort of serialized just gets trounced by the seemingly random release schedule. I think the all-at-once-model (like for S-Town) is much better for stories that are serial. Or, at least be ready to release it every week.[2] I probably should have just saved up all of Crimetown and binged it.
  • I bought a Zelda-Mario Player. It’s really fun.

  1. Time to switch to the mobile web interface, perhaps.  ↩
  2. The on-off schedule is fine for non-serialized shows like Science Vs. and Every Little Thing.  ↩

Biggest Current iOS Gripe

The barrage of notifications for calendar invites that you’ve seen and dealt with on other devices when you unlock your phone for the first time in a while is so horribly annoying. It’s caused me to inadvertently decline invites when I’m trying to swipe the notification away.

The calendar knows I accepted the invite. Why is it giving me this blast of prompts? I think this started in iOS 10, but I hate it.

If You Aren’t Already Using a VPN, Time to Start

I mean, everybody wants to make sure their ISPs can sell their data, right?

I was particularly saddened to see Rep. Massie on the list of those voting for this measure. Having worked for him (years ago), he is certainly smart enough to understand the technical implications here, but voted out of the idea that the free market was already doing a good enough job of this (i.e. Comcast won’t sell your data without your permission, for fear that you’ll leave for a competitor).

The problem is that, in great portions of this country, there’s no free market for ISPs. In most locations, it’s a local monopoly. I’m lucky: in my city, we have two cable providers, plus high speed fiber (fios). In the town I grew up in? One cable provider. And then DSL, if you live in the right spot. The house I grew up in? No DSL. No options.

Anyway, use a VPN. Most sites are using HTTPS these days, which is helpful, but your ISP will still know what name you looked up, what IP came back, and how long you were on the site. If you want to be careful, switch to an open DNS provider, and use a VPN. Most DNS providers will also use your data, but they will at least give you the option to opt-out. (As backwards as this sounds, I’d recommend Google Public DNS).[1]

For VPN, both Cloak and TunnelBear are reasonably cheap (probably less than you pay for 1 month of internet) and easy. Or, if you’re so inclined, roll your own.

  1. Google’s DNS privacy is pretty clear—“We don’t correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services.”  ↩