Developers are burning out as enterprises push them harder to drive digital transformation. IT automation and low-code platforms could help.
It’s a difficult time to hire talent, but particularly so for engineering expertise. With most companies turning to tech to transform how they engage with customers, software developers are in high demand. For companies hoping to retain their best engineers, and/or hire new ones, what are the keys to keeping developers happy?
According to a new survey from Salesforce’s MuleSoft, the answer might be to “empower the wider workforce to take some strain away from developers.” That is, to give non-developers the ability to develop. How’s that supposed to work?
SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)
First, stop doing harm
Given the pressure on developers to innovate ways to reach customers, it’s not surprising that so many developers say they’re burning out. Add to this the continuing reality of the Great Resignation, and there are often too few developers to accomplish too much demand on their time.
In the MuleSoft survey, the top factor contributing to developer burnout is an “increasing workload and demand from other teams,” affecting 39% of those surveyed. Related, 37% cite the pressures of digital transformation (37%) as contributing to burnout, while 35% say they’re struggling to learn skills that will help them adapt to new technologies and approaches.
This isn’t going to get better anytime soon. Not when 76% of organizations surveyed say the “cognitive load required to learn their software architecture is so high that it is a source of angst and low productivity for developers.” Over the past several years, we’ve loaded up developers with all sorts of new options (frameworks, databases, languages and more), but developers are increasingly eschewing “purpose built” options to find sanity in fewer, more general purpose options. It’s why enterprises increasingly look to internal platforms that remove developer complexity, and thereby improve their productivity, by limiting developers’ range of options.
And it’s also why enterprises increasingly look to low-code tools and other ways to bring what MuleSoft calls “business technologists” into the realm of software development. These people are “employees from outside the IT department who can play a more active role in digital transformation.” So, not developers, but capable of easing the load on developers. How so?
SEE: Business leaders as developer: The rise of no–code and low–code software (free PDF) (TechRepublic)
Help me to help you
Though 90% of enterprises surveyed say it would significantly help their developers if others could integrate apps and data for themselves, and 70% of these same respondents claim to have plans for doing so, the work to make it happen remains largely undone. Among the factors complicating such offloading to non-developers:
- Difficulty of managing the integrations across multiple cloud platforms without specialist IT skills (47%)
- Limited automation in software development (46%)
- Data silos (42%)
- Governance and security (41%)
- Limited access to lightweight tooling (38%)
Likening software development to automobile manufacturing, Matt McLarty, Global Field CTO & VP of the Digital Transformation Office, MuleSoft, said that automobile manufacturing had to fundamentally change to turn it into real business:
The job of building cars had to be broken down to make it accessible to the masses. We’re at that point in the software industry. We can’t expect a relatively small percentage of workers — software developers — to bear the brunt of mass digital production. We have to get the whole organization involved. Low-code tooling and automation technology are the means for doing that, and they’ve already been shown to improve employee satisfaction and reduce stress.
According to Forrester, just 10 to 15% of enterprises are currently using low-code tools like Unqork in earnest. However, Gartner predicts that 65% of all app development functions will be performed on low-code platforms by 2024. This may prove optimistic, but the relative shortage of developers, coupled with a surfeit of demand for their services, could accelerate adoption beyond comfortable timelines.
Disclosure: I work for MongoDB but the views expressed herein are mine alone.