What the Balls?

I’m going to start my own tech company someday and I don’t want it to be a failure. That’s why I can’t afford to forget this list of incredibly important things I’m learning along the way.

Rule #1: It must be dead simple for my developers to connect to the VPN.

You know what sucks as a developer? Getting a page at 8:23pm — halfway through your beer; four innings into the game — and having to fix something that broke. You know what sucks as a business-owner? Having to wait more than five seconds for the developer to be up and running on the VPN so he can start figuring out what’s wrong.

I’m not talking about the time it takes to get in touch with that developer or the time it takes for him to get home or whatever. You can’t anticipate those things and I don’t expect every one of my developers to perpetually be on call.

I’m talking about the time it takes from the instant he opens his laptop to the instant he’s actually able to start fixing problems. That time should be five seconds or less.

At my previous job, getting logged on to the VPN was horrific. The process was, roughly:

1. Go to http://oldjobvpn.com/.
2. Enter a username/password which I rarely used and may or may not remember.
3. Find my keys so I can get a six-digit number from my RSA token.
4. Make sure I’m doing all of this from Internet Explorer and have the right Java plugins or whatever installed.

Maybe that doesn’t sound so bad. Sure, there’s room for error but it’s just a few steps, right? I mean, I’m logged in now! What more could I want?

Oh, I need to actually deploy code?

1. Go to http://oldjobdevdesktop.com/.
2. Enter a username/password which I often used but was not necessarily the same as any other.
3. Fire up a remote desktop to the development environment and make my changes there, perhaps fighting with stupid things like screen resolution compatibility.
4. Go to http://oldjobtestdesktop.com/.
5. Enter a username/password which I often used but was not necessarily the same as any other.
6. Fire up a separate remote desktop to the testing environment and double-check my changes there, perhaps fighting with stupid things like screen resolution compatibility.
7. Use the same remote desktop to pull down the checked-in changes and deploy to production.
8. All of this at a snail’s pace because, after all, we’re talking about virtual desktops across the internet.

So I have to remember three separate username/password combinations, have my keys nearby, remind myself that I can’t launch the VPN from Chrome or Firefox, make sure I’m using the right remote desktop clients, and endure what could only be considered great bandwidth if it were 1996.

My word, did that ever suck.

At my current job, this is how I get on the VPN:

That’s it.

I should clarify that SSH is my preferred way to interact with my development environment, not a requirement of the infrastructure. If I wanted to launch Eclipse or IntelliJ or anything else, I could. In short, it’s completely as if I’m sitting at my desk, writing code the way I want to. It took less than five seconds: two mouse clicks, one password (my normal corporate domain password), and zero frustration.

Consider these two snapshots in time, sixty seconds after I open my laptop: at my new job, I’m looking through revision logs and diffs trying to figure out what change was made that broke things; at my old job, I’m still waiting for the VPN launcher to finish starting up.

It’s not just about crisis mitigation, though. It’s also about innovation.

Developers, generally speaking, like working on code. They can be utterly indifferent about the product but still want to improve the code base and implement their own ideas. Those ideas don’t have normal working hours. They could strike at 11:10am or 10:11pm and, either way, I want my developers to have the easiest possible path to putting those ideas into code.

If it takes a tedious, error-prone, blast-from-the-past process to log on to the VPN, I will get zero non-critical off-hours work from them. If it’s easy, though — maybe two mouse clicks and one password — they’ll have virtually no excuse to not hop on and hack a few lines.

So the case for a dead simple VPN is two-fold:

1. Something went wrong, it has to be fixed, and every extra second it goes unfixed is costing the business money
2. A developer’s desire to work for free is directly affected by the barriers to doing so and, as such, those barriers should be as low as possible

Sounds obvious when I put it like that, right?