I've grown concerned after running an enterprise API governance program. I review dozens of API designs, presented in the OpenAPI format, each week. In the past I've adamantly maintained that poor API design was a training issue; if we, as the enterprise, could better connect developers with the right resources at the right time then we'd see an increase in consistency and cohesion. Getting those materials created and distributed has been a point of emphasis.
But what if developers aren't meant to do API design? What if that is an entirely new, emergent skill set?
Before "Devops", enterprise software shops had numerous professional specializations: quality assurance, software architecture, software development, systems administrator, database administrator, etc. Each of these was recognized has having specific, deep expertise in a narrow field. The downside of having these channels, however, was that they became isolated from each other. "Tossing it over the wall" substituted for end-to-end project management. In the worst cases, when budgets or headcounts were under duress, all out trench warfare erupted.
Devops, especially the frothy conference buzzword type, was supposed to bring peace to those software shops. If infrastructure could be reduced to code, the thinking goes, then everything could be handled by the developers. Rather than having separate disciplines that devolve to defending their turf in times of trial, you just have developers and (in a condescending acknowledgement of reality) those that support them.
That extreme, all-is-devops viewpoint also is also problematic, however. In a previous job there was an impassioned embrace of devops. The existing sysadmins and database administrators were told, officially, that they were "legacy operations". Unofficially, management was telling seasoned, loyal professionals to pound sand. Perhaps unsurprisingly, six months later, production systems began falling over. The devops devotees didn't appreciate that Cassandra requires regular maintenance to avoid having its performance undermined by tombstones. Developers now had less time to do the things they enjoyed (developing) because they were relearning skills others had perfected (operations). Time to triage issues went through the roof because developers were relearning different skillsets. Couldn't those operations and database folks help out? Unfortunately not. They had sought jobs elsewhere; places where their experience was valued.
I was reminded of this from a recent API Evangelist post: GraphQL Seems Like We Do Not Want To Do The Hard Work Of API Design. I want developers to view API design as a core part of their job. I want them to see the importance of designing the API first, rather than being something they auto-generate from an implementation. I think these are complimentary skills and I certainly disagree with those that regulate API design to "documentation".
However, is that too much to ask from a majority of our developers? Is API design its own thing, no different than systems administration or architecture? Is it time to recognize the API designer as its own unique profession, complete with its own career path? Should we stop expecting a hodgepodge of different disciplines (architecture, developers, product management) to do this important work in-addition-to what they currently do?
