How you're losing developers' interest (and how to gain it)

You've got one "million-dollar minute" to get a developer's attention and make her productive. Here's how the best companies give developers a great experience from the start.

dev.jpg

Image: PRImageFactory, Getty Images/iStockphoto

In the time it's going to take you to read this article, you just might earn a developer's trust or lose it. Developers used to have to take whatever the CIO's latest round of golf imposed on them. No more. Spurred by open source (software) and cloud (hardware), the race to give developers what they want in a matter of minutes (or seconds) has become critical, as two database pioneers, MongoDB and InfluxData, have shown.

I want the world, and I want it now

The focus on a developer's immediate experience with a product isn't just for open source databases, of course. As Jared Rosoff points out, New Relic relentlessly focuses on a developer's first impression of their products: "Developers form their opinion about your tool in the first 60 seconds of digging into it."

Nor is it simply developers. As Miles Ward stresses, "If you are selling software, you should make it buyable in less than 3 minutes. Large, colorful button on your primary domain that says 'buy x now', pick sku's, capture whatever info you want for future upsell etc. Take my [credit card], but gimme the damned product. It's 2019." The internet has conditioned us to expect immediate gratification.

SEE: Tips for building a successful career as a software engineer (free PDF) (TechRepublic)

As pervasive as the expectation may be, it's doubly critical (and difficult) when dealing with developers, given their rising importance in the software purchasing process.

So how do the best companies ensure the developer's first impression will turn into a long-term relationship with their software?

Million-dollar minutes

Rosoff spent years at MongoDB, and tried to capture how it catered to developers. Not surprisingly, MongoDB didn't come up with its developer experience overnight, and getting that experience right was as much a matter of removing unnecessary details as anything else: "It required thinking through the whole developer journey—outside the product and in. Anything that's not core to understanding the product and what it does must be stripped away so new users get right to the core of what you do."

The first thing is almost certainly going to create fights with your sales and marketing folks: MongoDB doesn't gate downloads—it never has. Why? Because "if even one user DIDN'T try MongoDB because of that email address form, then we were sacrificing growth and future revenue."

SEE: 5 questions software engineers should ask in an interview (TechRepublic)

But how can we market to developers unless we know their name/email? You don't. Not initially, anyway. A developer cares a lot more about the software than anything you could tell them in an email, no matter how clever. Get that initial software experience wrong, or make it take too long to get to the software, and the only response you're getting to an email is "unsubscribe."

The second requirement is an easy install. "At MongoDB we built binaries for every target host OS and maintained the most popular installers in each of those platforms. Nobody should need to copy a binary from 'Downloads' to some folder." Related to this, that first experience needs to be hemmed in a bit: You don't want to lose the developer with complexity:

At MongoDB we worked hard to ensure that you could just start mongod without any options and it would work sensibly. This meant that you could download it and start it up without looking at the docs. Of course in real deployments you'd probably need to build a config file and make more choices, but that should be complexity you deal with later, not when you're first trying it out.

Importantly, MongoDB took this a step further, offering guided tutorials that didn't just help them get the system set up, but also "Help[ed] the user accomplish something on their first run with your product." That initial success, in turn, gives the developer the confidence to remove the training wheels on their next attempt.

Accelerating Time to Awesome™

InfluxData has taken many of the same steps in an attempt to "help[] developers and businesses get to results faster with less complexity and less code," as David Simmons highlights. Among other things, InfluxData ensures that all dependencies get installed without the developer having to think about it.

SEE: 20 programming languages that are attracting the most new learners (free PDF) (TechRepublic)

As InfluxData CEO Paul Dix told TechRepublic in an interview, however, developer simplicity starts well before an installation guide is written. Indeed, for InfluxDB, it's critical to identify upfront where the database fits, and where it doesn't. According to Dix, there's no intention for InfluxDB to be a general-purpose database. While time series is an abstraction that is useful for solving lots of different kinds of problems, and those problems exist pretty much everywhere, he noted, there's no desire to stretch InfluxDB into workloads where it may be a poor fit. "We think we can get better performance and developer productivity by focusing," he noted.

Where is InfluxDB focused? Four primary use cases: DevOps monitoring (e.g., application performance monitoring), real-time analytics, sensor data, and fintech (where time-series databases were first applied).

Developers will tend to start with whatever database they're used to or most comfortable with. This might mean that they, not InfluxData, will stretch their MySQL or whatever database to solve a time-series problem. This initial urge to use what feels comfortable will often bump into the reality of performance issues or unnecessarily verbose code to force-fit the general-purpose database to a time-series need.

Which is why InfluxData wants the initial experience to be so fast and easy for new developers. There may be just one chance to get them to try something new, something unfamiliar. That "out-of-the-box" experience therefore needs to be excellent.

So, if you're still letting sales and marketing get in the way of a great developer experience, don't. It's just not worth it. Software is eating the world, and developers are writing that software. Anything you can do to give them a great initial experience makes it more likely that they'll stick with you as they build the future. Trying to sell well before they're ready to buy is a serious mistake.

Also see

By Matt Asay

Matt Asay is a veteran technology columnist who has written for CNET, ReadWrite, and other tech media. Asay has also held a variety of executive roles with leading mobile and big data software companies.