Commentary: Are you interested in developing software for developers? These are the three design principles you should follow.
Jean Yang, founder and CEO of Akita Software, provides a thorough analysis of why there aren’t more programming language startup companies. She then identifies three ways to increase the chances that a developer-oriented product succeeds. Yang’s suggestions are valid, regardless of whether you’re building an open-source library or a proprietary CD/CI tool.
She believes design is the key to success, but not in its literal sense as developers may interpret it.
3 keys to great design of software
Yang says that design is about “reducing friction so developers can get to where it’s needed to go”, and not increasing prettiness or dialing in the trappings associated with good user experience such as cute error messages or dark modes. Design isn’t necessarily what a user sees on her screen. Instead, it’s how she interacts and uses the product.
And most importantly, what problem is the product intended to solve.
SEE: Research: Developers are not at risk from an increased use of low-code/no code platforms(TechRepublic Premium).
She said that functional programming enthusiasts often argue that their languages are better for developers because they have more guarantees and elegance. These arguments are not related to the high-priority issues that software teams are facing. Too many product development teams are too inward-focused. They are more focused on building cool things than building useful products for their customers.
Yang’s second principle emphasizes the importance of fitting into a developer’s existing workflow. “When I asked developers why tool X or Y was chosen, they answered that it worked well with their programming language or infrastructure or that it had the Slack/GitHub/Jira connections they needed. Some product managers are too optimistic and assume that developers will switch to a completely new toolchain to reap a small number of benefits. This is a nonstarter for most software teams. Even if the developer switches for a large set of benefits, this is a bad idea. It is almost always easier to stick with the workflow a developer uses every day.
Yang’s third principle focuses on packaging. The developer shouldn’t be left to polish a great product. She stressed that if this is a tool you will be using daily and sharing the results with others, then having a tool that has taken time to polish the edges, make it easy to see the output you need, and make it easy to do what you wish with the result makes all the difference.
All of this can be summarized as follows: Developer-obsessed developers will have the best tooling. They will be able to solve their most pressing problems in a way that is convenient for them. Yang is correct to say that these principles are more often spoken than practiced.
Disclosure: Although I work for AWS the views expressed herein are my own..