How to create successful developer products, according to Akita's CEO

3 years ago 351

Commentary: Interested in building software for developers? Better follow these three design principles.

In the midst of Akita Software founder and CEO Jean Yang's excellent analysis of why there aren't more programming language startups, she stops to identify three ways to improve the odds that a developer-oriented product will succeed. Whether you're building an open source library or a proprietary CI/CD tool, Yang's suggestions ring true.

The key, she says, is design, but not in the sense that developers may read that word.

3 keys to great software design

For Yang, "design" is all about "reducing friction to help developers get to where they need to go, not increasing prettiness or dialing up the trappings of good user experience, like cute error messages or dark mode." Design isn't necessarily what a developer sees on her screen, in other words, but rather how she engages with the product.

And, most importantly, what problem that product is intended to solve.

SEE: Research: Increased use of low-code/no-code platforms poses no threat to developers (TechRepublic Premium)

"I often see functional programming enthusiasts make arguments about how their languages are better for developers for technical reasons (more guarantees; elegance) that aren't related to the high-priority problems that software teams are experiencing," she said. Too many product development teams are overly inward-facing, in other words, focused on building something cool, rather than on building something useful to their target customer.

Yang's second principle stresses the importance of fitting into a developer's existing workflow. "When I asked developers why they adopted tool X or Y, the answer was often that it worked with their programming language or infrastructure, or that it had the Slack/GitHub/Jira integrations they wanted." Some overly optimistic product managers assume a developer "will switch to an entirely new toolchain to get a relatively small set of benefits. For most software teams, this is a nonstarter." Even assuming that the developer will switch for a relatively large set of benefits is a crapshoot. It's nearly always easier to stay within the workflow that a developer already knows/uses all day.

Yang's third principle is all about packaging. That is, a great product doesn't leave it to the developer to polish. "If this is a tool you're going to be using day-in and day-out and sharing the results with your team," she stressed, "then having a tool that has taken the time to smooth out the rough edges, make it easy for you to see the output you need to see, and make it easy for you to do what you want with the result makes a big difference."

All of which can perhaps be summarized thus: The best developer tooling will be developer-obsessed, wholly focused on solving their highest-priority problems in ways that are convenient for them. This may seem simple, but Yang is correct in arguing that these principles are often more often said than done.

Disclosure: I work for AWS, but the views expressed herein are mine.