As organizations begin to institute DevOps patterns and continuous delivery into their IT shops, one of the most dramatic long-term returns on their investment is that it bolsters the class and consistency of work produced by existing development teams.
Organizations that evolve to DevOps don’t necessarily need to hire rock star programmers to boost code and feature quality. That’s because, in the long-run, continuous delivery actually fosters an environment that makes it possible for the developers already in place to learn more efficiently and better improve the day-to-day quality of their work. The secret ingredient to this? Faster feedback loops.
“Shorter time to feedback is the key difference between DevOps and the traditional waterfall approach,” says Aater Suleman, CEO of Flux7 Labs and a professor in computer systems design and architecture at the University of Texas. “The main challenge with waterfall was the fact that there was a very long loop for feedback, which removed the agility from the picture. It could be a month or longer before developers would actually get feedback about what they’d done.”
The longer the cycle, the more code to sift through to find problems and the longer it takes to fix issues, says Curtis Poe, a consultant and Agile development coach for All Around The World. Shorter feedback cycles make it easier to find issues quickly and attend to them as soon as possible.
“Having continuous delivery means that typically very little code needs to be reviewed for failure and as a developer, if I get a bug report for code I wrote in the last hour, I’m going to be far more efficient in fixing in than for a bug report for code I wrote last month,” Poe says.
This is true not just for out-and-out failure, but also tweaking for improved performance.
“When frequent deployments are coupled with well-instrumented monitoring metrics on all aspects of your application, small nuances in performance can be detected and teased out for relatively small amounts of code change,” says Jeff Behl, chief network architect at Logic Monitor. “Developers want quick feedback to know changing this particular small part of code can affect this aspect of the application. The sooner you learn how to optimize the application code, the better.”
Even more important, fast feedback loops are not only critical for fixing past problems, but making sure they don’t happen again in the future. The shorter the time between when a developer writes code and receives information about how well it did out in the real world, the easier it is for them to learn from those lessons and apply them to future work.
With longer release cycles, be they quarterly or monthly, there’s often a lot of energy expended trying to find the person who created an offending line of code that broke something, says BLANK. The top triage person will go through the ringer to figure out who broke the code, until they might pinpoint something like, this person made this code commit six months ago that broke the application.
“Does anyone remember what they were doing six weeks ago? Of course not. But if you were writing code at ten o’ clock and I came by at one o’ clock and told you exactly what was broken and I sent you a zip file that had everything that you needed to do to reproduce that on your desktop do you think you’re going t o be a better programmer?,” Gary Gruver, vice president of quality engineering release and IT operations at Macy’s said last fall at FlowCon, explaining that every developer wants to do a good job and is typically trying to do the best job that he or she can. “If you can’t provide them that rapid feedback , real-time in an efficiency manner, how do you expect people to get better?”
In the scenario above, the process of developing the offending code is long gone in a developer’s memory, which means it takes more work for the coder to review their work, remember the project and then mentally link that process to the infrastructure dependencies that were affected by it. With shorter cycles, devs spend less time remembering what they did and more cognitive work on understanding dependencies and the context in which the code operated. Long-term, that’s going to make for better code from the get-go later on.
“Developers who can understand how their applications work under additional loads, abnormal conditions, and degraded circumstances, will end up designing better applications and systems, and in the end play a more strategic role at the company,” says Arnold Goldberg, vice president of customer engineering for PayPal.
According to Goldberg, context in development is critical and the faster, richer feedback provided by DevOps allows developers to better understand how application improvements work in production context. And that is huge for informing best practices.
“Much of it is specific to the fabric of the existing organic infrastructure that a company has, so it needs to be a pragmatic application of it in the context of the company’s current situation,” he says.
Faster feedback loops aren’t just about making technical coding improvements, either. These more rapid assessment cycles can also greatly improve features and business value offered by developers. We’ll explain more in part two of this series.
