6 Things to Consider When Creating Apps for Other Developers

There are two kinds of apps in the world: those intended for non-technical end users and those designed for developers. Depending on your audience, the process you rely on to develop, deploy and manage your app may vary significantly. After all, developers have different needs and expectations than typical end users. Here's a primer on how application development needs to be different when creating apps specifically for developers.

What Is a Developer App?

If you're a developer, you're already familiar with apps for developers. Such apps include tools like IDEs, CI servers and release automation platforms. Git and GitHub are also examples of commonly used developer apps. So are, in a broad sense, the entire cloud platforms (and the various configuration, deployment and monitoring tools they entail) of vendors like Amazon and Microsoft.

These types of apps are distinct from what you might call general-audience apps that are intended for use by the lay public. Facebook and Instagram are general-audience apps. So is an app you use to order takeout or manage your bank account, for instance.

How Developer Apps Are Different

Obviously, developer apps serve a different purpose than general-audience apps. But it's not just use cases that set each type of app apart.

An effective developer app is designed, deployed and maintained in a fundamentally different way than a general-audience app. Here are six things to consider when creating apps for developers.

1. Stability vs. features

You could debate this point a bit, but I’d contend that one thing that makes developers different from the typical end user is that most developers would rather have stable apps than feature-rich apps.

This can be an easy point to overlook in the present age of continuous delivery. Today, developers are told that they must “delight users” by delivering constant improvements when creating apps, lest their users run to the competition.

That may be good advice to follow if you are catering to general-audience users, who (if the consumer apps I use everyday are any indication) are willing to overlook bugs as long as you keep giving them new features to play with.

But the fact is that developers who are relying on an app for mission-critical coding work would probably rather have rock-solid reliability than a slew of new features. There is a reason why projects like Debian (which creates a Linux-based operating system used largely by developers) churn out new releases only every several years, whereas an app like Facebook seems to have a new feature on offer almost every time I log in.

So, if you’re creating apps for developers, you might want to interpret the continuous delivery philosophy conservatively, and push out new features only when you’re absolutely certain that they won’t undercut stability.

2. Interfaces

Developers also differ from typical end users in that they tend to want not just a graphical interface, but a command-line interface, too.

In some ways, this defies stereotypes about developers. We often think of programmers as CLI warriors who never want to touch a mouse or a graphical display.

In reality, some developers (especially those who come from the Windows half of the universe) do like working with GUIs. Others (the die-hard Linux hackers) prefer only CLIs. And still others like to be able to pick and choose between the interfaces they use, depending on their needs. Sometimes, a GUI is more convenient for simple tasks, whereas a CLI is a must-have for helping to automate large-scale or repetitive tasks.

The lesson: Make sure your developer app offers both a GUI (whether it’s native, Web-based or both) as well as a CLI.

3. Cross-platform support

Just as developers like options when it comes to the interfaces they use with their apps, they also like to be able to run apps on their favorite operating systems. The typical end user might not put up a fuss when you say your app is only for Windows or only for iOS, for example, but developers probably will.

Indeed, part of the reason why Docker containers became so popular is that, although Docker containers themselves were originally a Linux-only technology (they now work on Windows, too), Docker introduced developer toolkits for Docker that could be used on Windows, macOS and Linux. In other words, developers could build Docker containers from a developer box that ran any major operating system, even if they could only deploy them to Linux.

Windows Subsystem for Linux and cloud IDEs have become popular for similar reasons: They free developers from the restriction of having to run a certain kind of operating system.

If you’re creating apps for developers, heed these precedents and make sure that your app supports all of the major operating systems, too--whether it runs locally or in a browser.

4. Deployment modes

Here’s yet another area where developers like choice: application deployment.

Typical end users will be happy enough if the app you create for them can be installed only locally, or is available only as a Web app hosted in the cloud.

In contrast, developers don’t like being told that they can deploy an app only in a certain way. They want to be able to run it in a cloud-based virtual machine if they wish. They also want to be able to containerize it if the fancy strikes them. They want to be able to install it on their own infrastructure, or in the cloud.

Thus, to reach developers most successfully, let them deploy the apps you build in whichever way they want. Don’t force them to use a certain deployment technology or model.

5. Logging

I’m pretty sure that the typical end user only vaguely knows what an application log is. Many general-audience apps don’t generate logs that are available to the user, and, even if they do, most of their users would never be able to find the logs anyway.

Developers, on the other hand, love logs. They use them to figure out what went wrong. They turn to them to optimize performance or research security events. So, when creating apps for developers you’d better be sure it generates logs that are easy to find and interpret. Bonus points if you include features that let developers customize logging operations.

6. Open source

I’m also pretty sure that most end users have only a vague idea of what open source means. (Many wrongly tend to think it means “free of cost,” plain and simple.) They don’t care much about whether their applications are open source. You can’t blame them, given that most can’t read source code, anyway.

But developers do tend to have a preference for open source. This isn’t to say that developers will eschew your app if it’s not open source; there are some successful developer apps out there (like basically everything running in the public cloud, for example, or most APM software) that is decidedly not open source. But many of the most successful developer tools (like Jenkins, Kubernetes, Eclipse and Grafana, to name a few) are open source.

Unless you have a good reason not to make your developer app open source, learn to love the GPL (or MIT License, or Apache 2 or whichever open source license floats your boat) and go open source.

Conclusion

Developers are a different breed of user. The apps that delight the average user will often fall short of meeting developers’ expectations. When creating apps for developers, keep their unique desires in mind.