Brandsit: What factors contributed to the concept of DevEx? Is it a response to any specific challenges in the IT industry?
Maciej Żwirski, Deloitte: The components of the DevEx concept are mostly not new. The methodologies, tools and performance measurement metrics that DevEx describes are already successfully in place in any self-respecting manufacturing team. What is new, however, is the attempt to interrelate them, which sometimes amounts to, to put it bluntly, an attempt to control chaos.
In my opinion, this is a natural consequence of the maturation of the industry and the industrialisation of the software development process. As an analogy, let’s take an industry with a much older pedigree – manufacturing, for example of cars. Imagine that each section of the assembly line was supplied by a different manufacturer. It requires different training, certifications and authorisations from the operator. Each screw has to be screwed in with a different spanner, with some spanners being operated with the right hand and some with the left. On top of this, someone occasionally brings in a self-designed seat announcing that “it has to be attached to the whole thing somehow”.
The example may seem exaggerated, but many developers work in such an environment. They have access to dozens of tools, but each is responsible for one specific activity: code is stored separately, artefacts are stored separately, tests are run separately… The so-calledcitizen development – i.e. low-code software configured by the “business” – adds further complexity.
The concept of DevEx indicates that companies that want to talk about the ‘manufacturing process’ should take care to standardise the environment in which this process takes place, while at the same time taking care of the people who perform it.
Brandsit: What are the main benefits for companies and their technology ecosystems of leaning into the developer experience? What changes might they observe after implementing DevEx-focused practices?
Maciej Żwirski, Deloitte: In a nutshell, we can say that these are lower software development costs resulting from higher code quality and better employee retention. According to the Harvard Business Review, you can see a more than twofold increase in engagement and an 85% increase in retention over three years among employees who work with technology that supports them rather than hinders them.
Running the development process on a single, integrated technology also has many benefits. The cost of training and certification decreases, as the portfolio of tool suppliers is reduced. In such a process, it is easier to produce reusable components. Such a process is also much easier to measure.
And here we come to the ‘people’ part of DevEx. We are seeing a gradual move away from measuring developer productivity by the number of lines of code delivered, ‘commits’ and, in extreme cases, hours worked. What is being measured is the time it takes to deliver complete functionality and the reliability of the delivered software. And this, too, is nothing new. On the other hand, it happens that in the flurry of ‘stories’, ‘burndown charts‘ and ‘epics‘, we forget about these basic metrics.
Brandsit: Could you share examples of controversies or challenges you have encountered in implementing DevEx concepts in different organisations?
Maciej Żwirski, Deloitte: There was perhaps not so much controversy as some difficulties inherent in any change process. Because while some elements of DevEx can be done evolutionarily (e.g. aligning the technology stack), organisational change already requires cumulative action. It is also where many of the transformations we have witnessed have been stuck. “On paper”, everything seems simple and obvious: we create a process, promote a more “human” approach to developers, foster knowledge sharing, cooperation between departments and the result is an organisation where technology experts work hand in hand with business experts for the common good.
However, going into the details, we come up against a whole range of obstacles. Habits, ambitions, internal frictions, fear of change or even the mundane lack of time or budget. This is where our change stops being technical and becomes adaptive – and as such, it requires a determined leader, subtlety and, above all, time. And we all know that we can have everything in abundance, but time is always in short supply.
Brandsit: What future developments do you foresee for the DevEx concept? Are there any new tools, practices or methodologies that could intensify interest in this area?
Maciej Żwirski, Deloitte: In my opinion, DevEx will combine very well with generative AI in the coming years. Personally, I stand by the opinion that artificial intelligence, in professional applications, will support us, not replace us. In the case of software development, it can take the onus off developers to painstakingly create (let’s face it – copy) repetitive code. If used correctly, it can also increase its quality. I finished my coding adventure longer ago than I’d like to admit, but at the time I would have given a lot for a tool that offered me a block of code that I could just review and adjust. Anyone who has ever written code will also admit that there have been times when you’ve lost hours of your life looking for a misplaced semicolon or comma. The chances are that GenAI semicolons won’t be lost.
Looking further into the glass ball, I would also predict that development teams in the future will be made up of fewer well-trained professionals. This does not mean, of course, that we should expect a decline in the number of job offers. Although such a decline can be observed at the moment, I believe it is temporary and is related precisely to transformations within organisations. A report by the Bureau of Labor Statistics of the US Department of Labor indicates that the demand for programmers will increase by 25% over the next decade.
Brandsit: How can improving DevEx make a company more competitive in the technology market?
Maciej Źwirski, Deloitte: Streamlining the software delivery process, bypassing all intermediate metrics, translates into a shorter time-to-market. This means a lower product cost, but also the ability to deliver more functionality at the same time. And this gives, in a market as dynamic as technology, a substantial advantage. In most business projects we see, software is often on the critical path. Which is acceptable if our product is just software. But if we are a bank, a car manufacturer or a transport company, software is our tool, not our product. And as a tool it should support us, not block us.
Whoever is the first to ‘remove’ this blockade – will be able to dictate terms to their competitors, at least for a while.
