Perfecto CTO: the changing role of the developer
Uzi Eilon is chief technology officer at cloud-centric continuous testing company Perfecto. As CTO of a test automation specialist, Eilon says he has seen software application developers have to take on responsibility for faster and more frequent releases in recent years.
He says that the most significant change for developers in the last decade has been the shift from Waterfall development methods to Agile.
Eilon now writes for the Computer Weekly Developer Network to examine the pace of change in modern development practices and ask what programmers need to do to remain successful, productive and healthy.
Eilon writes as follows…
Ten years ago, when we followed the waterfall methodology, the accepted way of working was to design and lay out the entire project prior to beginning development. This usually entailed a big process of gathering app requirements, designing flows and planning the test methods. It took months to deliver the first resale which meant both developers and testers had plenty of time to test the app. Once a stable version was released a ‘code freeze’ started, which meant waiting for the QA inputs so we could focus on rectifying the bugs.
This approach simply doesn’t work anymore, because too much time and effort was wasted. Agile processes have brought about a complete about turn – helping teams move to focused, small and iterative work – and, as a result, allowing us to develop and deploy services much more quickly.
The need for training
It’s this need for speed and fast feedback which has driven many of the changes we’ve seen in software development. In particular, our responsibilities as developers have massively increased over the last decade. Where testers, developers and quality assurance (QA) teams once had distinctly different jobs to do, the functions are merging.
We now wear many hats and, the complexities we face aren’t necessarily the ones we signed up for. As well as writing code, we now have to focus on enhancing and improving customer experience, boosting service efficiencies and lowering costs.
Understanding how stable the current version of the app is, we can either continue with developing new features or focus on quality improvement. If there is an issue with the app, we should be able to analyse the problematic area by understanding the flows and the connection between the different components.
The need for sharing
Today we have the benefit of open source. We can avoid wasting time reinventing the wheel; if we have technical difficulties, the solutions can usually be found on one of many developer sites. Good developers share their knowledge — fix problems and share know-how with the rest of the community.
The need for testing
In the past, we used to 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.
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.
When we developers ‘own the quality’, continuous testing becomes 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.
A fundamental change
This is why 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 to help us deliver quality code and stable automation tests.
Today we are part of big communities and our role is not focusing on one specific development language, but instead, being able to find the right components and build the most efficient and flexible code.