DeveloperWeek Tackles Continuous Delivery and Uncertainty

At this week’s virtual DeveloperWeek Global conference, Robert Barron, AIOps lead at IBM, spoke about concerns and opportunities software developers face as they feed the demands of modern development. Pressure to deliver might push developers to forge ahead despite issues they know may lurk in the woodwork. “We want to reduce all the uncertainties of ‘Will we launch public? Will it succeed? How much will it cost? Do I know what I’m getting into?’” Barron said.

Addressing such questions has spurred demand for automation, microservices, CI/CD pipelines, and less heavyweight code deployment, he said. “We want to reduce the cost, the danger, and uncertainty of deploying a new application to the cloud.”

Barron compared such wants with the eagerness in the 1970s of NASA to increase access to space, which led to the space shuttle program to fly to space more regularly. That led to increased democratization of space travel and expansion of capabilities such as the repair of satellites in orbit, a task Barron said would not have been possible in prior decades.

Modern computers may dwarf the compute power in now-defunct space shuttles, but he said space-based computers are becoming more and more powerful. “We have started seeing computers in space able to run regular microservices,” Barron said. “Development for computers in the international space station is becoming more equivalent to development in the ground.”

Discussing the Space Shuttle Challenger disaster, Barron spoke about concerns engineers raised prior to the fateful launch and how the addition of more information about the conditions of prior space flights might have affected decisions made that day in 1986. “What the engineers were being asked to do was not prove that it’s safe; they were being asked to prove that it’s not unsafe -- a negative, which is much more difficult to prove,” he said.

Damage to O-ring seals in the booster rockets, which were later identified as major factors in the Challenger disaster, had been seen in previous flights, Barron said. That recurring issue led to what he described as normalization of deviance. “The position is ‘We know there is a problem; it’s not desirable but we haven’t convinced ourselves that it’s dangerous,’” Barron said. The more often the problem occurs, it can lead to more of feeling that the irregularity is not really an issue, he said. “By definition, it’s working despite some abnormalities.”

Handling technical debt, in that instance, became less important than succeeding in the next mission, Barron said, which he likened to pushing the deployment of the next version or feature of an application. Turning to an analysis of the later Space Shuttle Columbia disaster, he said actionable information on possible risks was buried deep in the report. He compared that issue with modern monitoring systems, where spikes show problems in performance, but the problems are regularly resolved. That can lead to a presumption that the problem is transient and might be ignored -- until calamity strikes, Barron said. “This little problem that’s been following you along is going to snowball into a disaster. It’s very easy to ignore an anomaly that doesn’t cause a problem.”

Something that is “almost broken” might not get fixed, he said, because it has yet to break. Barron said the shift from the Safety-I to Safety-II school of thought calls for no longer just avoiding issues and instead focusing on ensuring everything works properly. “The fact that something was okay in the past doesn’t mean it’s going to be okay in the future,” he said.

Developers need to be able to explain and justify their perspectives, Barron said, with documentation and through collaboration between organizations. “A large failure in troubleshooting, solving problems, and avoiding problems is because someone knows something but doesn’t know who to communicate to, how to communicate it, or doesn’t want to communicate it to others,” he said.

Barron suggested using minimum viable products to define the vision of a software release and taking small steps to achieve business goals that lead to new business goals.

“The technology is just the means, it’s not the end,” he said.

Related Content:

11 Ways DevOps Is Evolving

Continuous Delivery: Why You Need It and How to Get Started

Why DevOps Will Have To Change This Year