Despite appearances to the contrary, developers are on balance a happy bunch. But only just.
Recent research from Stack Overflow showed that 14.4% of developers were positively unhappy about their work, while 15.3% were merely indifferent. Whilst it should be noted that the sample size was small, this still implies an ongoing drain on your overall effectiveness, and a catastrophic hit should they stop merely looking towards the door and instead get up and walk through it en masse.
We can’t say what specific problems individual developers have. But we can speculate that developer experience, the tools and techniques developers use to do their work, can have a real effect on their individual wellbeing and productivity, and by extension that of the entire organisation.
Whilst companies including the Financial Times, GitHub, Monzo, Spotify, and perhaps most famously of all Netflix have all made a successful investment in DevEx tooling, Capgemini’s head of software engineering, Stuart Williams, suggests that many organisations’ decisions about platforms and tooling start from the wrong place. “The organisations say we have lots of apps, we should have a common platform. And then they start to work ground up from what a common platform should be by looking at what Amazon does”—without really thinking about how their needs might be different from that of the world’s biggest retailer and cloud services company.
Unsurprisingly, individuals or teams then find their projects don’t particularly fit with this approach, and declare, “We're special, we're not going to come on the platform, we're going to do our own thing”. Corporate politics inevitably plays a part.
“You instantly get this kind of buildup of resentment, because you can't get your point across using a JIRA ticket,” adds his colleague, Sarah Saunders, managing software engineer for cloud and custom applications. “You would never build an application like that. So why do we think that we can build a platform like that?”
So, is the solution to give engineers the power to decide on and develop the precise tooling and platforms they think will make them more effective?
It’s a thought, but as Container Solutions’ engineering manager Hannah Paine says, “Every single engineer is going to have their own view of what the most important thing is”. And by extension, what the best approach is to fixing problems. That multiplicity of views means that decisions on tooling strategy are often reached by consensus and that, says Paine, “is not decision making”.
It’s certainly not the product management approach most sensible organisations take when it comes to building the products and services they deliver to their end customers, or indeed non-technical internal users.
Precise definitions of product management will vary, but the core idea is that a specific person or team is responsible for guiding the success of a product or service, talking to customers and users as well as business and engineering teams, and figuring out what actions can be taken to meet their needs. As well as technical knowledge, it requires an understanding of the organisation’s strengths and weaknesses, as well as a grasp of the broader market it operates in.
The irony is that companies, particularly tech companies, are stuffed full of product managers. It’s just that in many cases they’ve not been applying this approach to their own devs and the tools and platforms they build and use.
Which begs the question, what happens when you do turn this approach to the tooling your organisation builds for its developers?
Market and user research is part of the product management mix. But this might seem to be a challenge when it comes to internal product management. The user base might be comparatively small, and it might seem difficult to generate statistically significant responses, with the loudest or most dogmatic voices potentially drowning out others.
Prodding your way to improvement
But this is technology we’re talking about. And the nature of platforms today means that quite apart from the end results–the thing that is delivered to users–there’s plenty more than can be measured.
Jelmer Borst is product manager for platform products at Dutch grocery etailer, Picnic Technologies, which has an explicit commitment to recruiting product managers to manage its own internal tooling.
“In our case, we're actually crunching through numbers,” he says. “What are people doing in, for example, Git and GitHub? How much time are we actually spending on certain tasks? How quickly do we go from idea to production? How much time are we spending on incidents? And how many do we have to begin with? So how quickly are we able to resolve them?”
Many of these metrics are, or should be, broadly understood by software folk he adds, having been spelled out by DORA or Microsoft’s SPACE framework.
The result is that, “By improving the setup and reducing the time spent to go from idea to production, you are able to have basically a lower time to market for your features”. The knock-on effect is that the team doesn’t just deliver that feature faster, but also the next one, and the one after that. “Which means basically, your iteration speed is higher, which means you're able to deliver faster to your end users.”
Paine echoes the point of working on things you can easily measure, like build time, and build success rates, but also emphasises the importance of less tangible issues, like happiness and the enjoyment of using the tools. These still have real world consequences, she points out, such as non-take up of tools, sick days, and unhappy developers leaving the organisation.
“It's all too easy for investment where you can't see a tangible outcome to stop, unless you can say, this is why it's successful. This is why it's worth us spending our money on this.”
And it’s important to consider those issues of autonomy and flexibility, she says. “You have to be very careful about balancing improvements to developer experience and tools that lessen the cognitive load, but don't take away from their flexibility and the things that they enjoy.”
Williams at Capgemini cites the “unicorn problem” when it comes to getting platform development right. Unicorns being “the people who can write code, build apps, build the infrastructure, build the build pipelines, do all the things”. Magical basically, as Saunders puts it.
Someone who started their career ten or 15 years ago might have knowledge of all these areas, after an “iterative” learning journey, encompassing the Agile Manifesto, followed by the dawn of DevOps, then the onset of containers, Cloud Native and beyond.
But, he continues, “If you are 22, coming out of university, and now you need to start to understand all of this… if you can do that, you're brilliant. And you'll get hired by a huge tech company for a massive salary. And therefore you're now a unicorn.” And unavailable to most companies.
The solution is in part, Williams says, “to NOT build systems that need unicorns to drive… you need to understand what developers needs are, you need to understand that you can't overload them with too many knobs and levers. You need to build things for them that are good enough that they self-select to use them.” A point which Sarah Wells echoed on a recent podcast episode.
The result, according to Williams, should be that “your overall position and risk profile improve, because people are using well-governed templates. You don't need to send every project to a Change Advisory Board or Technical Design Authority for approval, because they're pre-approved.”
The platform engineers benefit too, says Saunders: “They're not creating the boring stuff over and over. When they've got problems to work on, they’re problems outside of this paved road, which are interesting for them.”
So, internal product management can deliver value. But who should be taking responsibility for this role? Clearly it straddles domains. As Paine says, “I think a product manager who is able to articulate value to the business—as in whoever your purse strings are held by—as well as communicate successfully with the users, is so important.”
But she adds, “I think it's a rarity that you would find engineers who can or want to do that kind of thing”.
Can it happen fast enough?
Perhaps even this approach is missing the point. Tudor Gîrba, CEO at Swiss software consultancy feenk argues the problem is software itself is “highly contextual” and most organisations have only the vaguest idea of how their systems are put together. “We can predict classes of problems, but we cannot predict the specific problems people will encounter.”
His organisation has produced the Glamorous toolkit which features 2000 custom tools, including code analysis tools and a code editor, to help devs map out the systems they’re working with and build custom tools for the specific problems they encounter, in contrast to the usual model of trying to build universal, repeatable tools and approaches.
He describes this approach, which we’ve explored previously on WTF, as moldable development. We’ve already moved to infrastructure as code, and he predicts “Tools will become code.” The aim is to bring down the cost of an individual custom tool to “so low, that it doesn't matter anymore, so that we can enable new workflows.”
It’s a radically different approach, and Gîrba accepts it will take “five to ten years for people to figure that one out.”
So what do the rest of us do in the meantime? Well, a product management approach may help enlightened firms shrug off the shackles of overly prescriptive systems imposed from above, while evading the potential anarchy of leaving everything to individuals.
It’s clear the first step is to start talking to your people—whilst being fully aware that this will not necessarily give you the full story.
Borst said other than talking to your team, the key is to “Get control over the data, start measuring the main metrics for your team, start doing improvements. And then you measure over time if you are actually improving.”
Picnic has put its code where its mouth is, by open sourcing Error Prone Support, which encompasses a range of BugCheck and Refaster (refactoring) rules which can be used with Google’s Error Prone Static Analysis tool for Java Code to pick up bugs before they find their way into its codebase.
And Paine says make sure developer experience, including happiness, is part of the process and related to measurables. But, she adds, keep an open mind and bear in mind that what looks arduous and complex to an outsider might be precisely the thing that keeps a developer or engineer engaged.
“There are definitely some engineers who really enjoy being able to use a command line to do whatever”. Take that away, she warns, and “you’ve failed to improve your developer experience.”
Previous article
