‘Change is the only constant’, is a well-worn phrase that has special significance for developers. We all know that the role is constantly morphing – and as enterprises are increasingly pressured to deliver fast and frequent releases, developers are finding themselves taking on more responsibility than ever before.

So, how has the role changed over the last decade? And more importantly, how can developers cope with the pace of change they’re facing now? During my fifteen years in enterprise software development, I’ve witnessed much of this transformation first hand; as I helped develop products and solutions for optimising software quality and application lifecycle management – all against the backdrop of a fast-changing and unpredictable business environment.

The need for speed

The most significant change in the last decade has been the shift from waterfall development methods to agile. Digital transformation is accelerating the adoption of agile because digital is the main portal to customers and the customers’ expectation is to get more – faster and easier.

In a world where a bad review can go viral in seconds, better apps and faster service have created a make or break scenario for vendors – customers are much less tolerant of bugs and issues. In addition, fast innovation by handset manufacturers and operating system makers has created a continuous stream of innovation opportunities e.g. easier, more secure authentication using biometric support and new workflow opportunities, such as using pictures as part of the insurance claims process. Agile makes it possible to increase velocity whilst ensuring quality, but it brings some challenges too. One hurdle when making this move has been getting to grips with the concept of iterative development.

For waterfall organisations, the accepted way of working has been to design and lay out the entire project prior to beginning development. Of course, this might entail months of requirement gathering and design sessions before a team could even begin working on code and during this lengthy process user requirements may change: what was once appropriate no longer fits, resulting in wasted efforts. Agile processes have caused a complete change in direction, helping teams move to focused, small and iterative work and, as a result, allowing them to develop and deploy services quicker than before.

Of course, the shift from waterfall to agile, which went against developers’ previous training and experience, caused apprehension for many. This is normal and was expected. But the clear benefits of the agile methodology helped developers to immediately recognise its value.

And, for us, the primary value of agile is speed. Agile creates fast feedback opportunities between developers and users, enabling faster course correction and improved quality.

Indeed, it’s this need for speed and fast feedback which is a driving force behind many of the changes we’ve seen in software development – and it’s the reason, too, for development teams’ responsibilities expanding exponentially over the last decade. Where testers, developers and quality assurance (QA) teams once had distinctly different jobs to do, the functions are quickly merging and dev teams are now tasked both with making apps and services and also ensuring they are of the highest quality.Q

The need for training

The developer now wears many ‘hats’ and, of course, the problem for some is that these hats aren’t necessarily the ones they want to wear, or even signed up to wear! As well as writing code, developers find themselves focused on enhancing and, improving customer experience, boosting service efficiencies and lowering costs. All vital jobs of course, but very different from what they were initially trained to do.

Let’s take microservices as an example. The deployment of microservices (the loosely coupled, autonomous, fine-grained services which many commentators see as the holy grail of modern development), is a sea change for many. Deploying many microservices to a shifting number of users means that app deployment is getting much more complicated, and so no longer falls under a pure-play developer’s remit. Instead, it becomes the role of a wider, frequently shared, DevOps function, which has responsibility for the whole product development and production lifecycle, and which is the function where many developers now sit.

So, in this world, where job functions are increasingly fluid and complex, it’s important that organisations are committed to upskilling their developers and sharpening skill sets towards the goal of automating key activities during the DevOps pipeline. As always, speed is crucial and teams must focus their efforts on improving the processes that are slowing them down.

We believe that leadership is a critical aspect of helping developers seamlessly transition to what essentially constitutes a new job role. Diverse teams and personas call for strong leadership as a unifying force, and a leader’s active role in affecting change is crucial. Of course, part of leadership is to enforce stringent metrics and KPIs which help to keep everyone on track. The continuous measurement of both development productivity (the number of user stories per sprint) and quality measurements (the number of defects per release) are imperative.

The need for testing

In the past, we saw developers follow a linear process when it came to testing. Committing code without testing, or with minimal testing, wasn’t a problem when QA teams were on hand to catch issues and fix them. But today the QA phase has gone (at least in mature shops), and the iterative development process that is the hallmark of the new DevOps world means that testing and quality assurance needs to happen in tandem with development.

And, just as the developer’s role is changing, so too have our ways of measuring: not only our progress but also the effectiveness and performance of our code, tools and processes. This increased visibility is a good thing and helps to catch issues early. And, when the developer ‘owns the quality’, continuous testing becomes absolutely crucial; it’s key to improving quality, extending coverage, speeding up development, reducing costs, and saving man hours, and the de facto requirement to achieve the development speed objectives of modern development teams.

And it’s with this plethora of reasons that we now see so much emphasis put on test automation. The development process has been fundamentally changed – commit code is not complete without commit tests alongside it, and new test tools and platforms have been developed in order to help developers deliver quality code and stable automation tests.

Evolution for responsibilities

So, the development world has fundamentally changed over the last decade. And there’s little doubt any more that DevOps has evolved from being the bright, shiny object that everyone talks about, to be the necessary reality. Developers, as part of the DevOps function, now have significant responsibility in an enterprise. They own the availability and sustainability of the customer experience – and that can make or break a business.

But, we recognise that, for a developer, this merging of roles we’ve seen over the last decade can be tricky. As a developer, it may be that you have always been spending a fair amount of your time on the Ops side, but now it’s your responsibility to do both. And much more besides.

Of course, it’s difficult to have at least half your job consumed by doing something you didn’t necessarily go to school to learn, but this increased responsibility can be vital to the success of a business. In recognition that their role is a crucial one, it’s our responsibility as an industry to help developers cope with the change.

Written by Uzi Eilon, CTO, Perfecto (America)