The 2000 film “The Perfect Storm” was set on a portion of the North Atlantic Ocean known as the Grand Banks. It’s where the cold, southerly flowing Labrador Current meets the warm Gulf Stream.
Warm water rises, cold water plunges and plankton flourishes in the oxygen- and nutrient-rich Grand Banks. The entire food chain propagates, including fish that gather from all over. It’s one of the richest fishing grounds in the world.
For the crew of the commercial vessel Andrea Gail, the exchange point of warm and cold currents in the Grand Banks and, further east, the Flemish Cap, was an opportunity for a massive haul. As the ill-fated voyage showed, however, there also was extreme danger in going there.
For me, there’s a comparison to be made between the exchange of sea energy in the Grand Banks and enterprise software development. In each case, there is the potential for both huge opportunities and enormous risks.
In development, the handoff time between teams or individuals can be fertile grounds for efficiency, or to enhance and improve a project. Conversely, it can be a chance for critical errors to be introduced.
Another Comparison: Medical Errors
Consider for a moment another field: medicine.
Some 80 percent of serious medical errors occur because of bad communication at the point of handoff – from one doctor to another, from doctor to nurse, from patient to doctor, and so on.
In patient care, you can’t translate all of the knowledge from one doctor to another practitioner on a piece of paper or tablet or even orally. This problem propagates as individuals specialize in a specific area or task and will only get worse as research gets broader and deeper.
The problem here is perhaps even more similar to software development, where studies have traced many errors back to the handoff or exchange on projects involving multiple teams, partners or contributors.
The Error is in the Exchange
So, you see, enterprise software development is no different than a lot of other areas. Sure, the risks are different. Lives aren’t at risk, not usually, anyway. There are, however, financial risks when pushing code into production, something we do faster and more frequently than ever before.
Sometimes you can’t get all the bases covered, and holes are left in the chain that allow for errors. Just ask Target, which recently was breached and had 70 million credit cards stolen from somewhere in its software delivery supply chain.
Application development is wrought with opportunities for such problems, and now we’re going to add speed to the entire process by removing constraints and automating more than ever.
Enterprises need some answers, and fast.
Enter DevOps
Along comes the DevOps frenzy, which promises to turn the potentially hazardous exchange between development and operations into an opportunity for faster, smoother apps.
Except for this: DevOps really isn’t a thing to be selected off a menu or a price list. It’s not a function that one person can execute. It’s a way of life – a culture. Implemented carefully, the DevOps culture can help enterprise software finally catch up with all the other industries in terms of efficiency and quality.
Manufacturing industries figured this out a long time ago. Think back to your history classes and your studies of Eli Whitney, Henry Ford and the Industrial Revolution. Components were designed to be interchangeable. Tasks were split up to speed the throughput of the entire process. Quality and efficiency both went up.
Don’t Take It from Me, Ask Your Teams.
Go to your teams and look at the exchange/handoff points. How many times is code handed from one person or team to another? Is the exchange manual? What would happen if you were required to add more speed?
Chances are, your first reaction would be to have people work more hours or have them solve their own problems. This would only increase the number of handoff points, raise the risk of errors cause a debt to your delivery schedule.
Don’t take it from me. Ask your teams. How would they envision speeding up development while improving quality? Chances are, they’ll agree:A better option is to automate application and delivery.
Through automation, machines can perform an enormous amount of work while freeing your engineers to focus on what they’d rather be doing – creating apps that better serve your customers.
Exchange points can continue to be your Achilles Heel as an development organization. Or, it can be your chance to shine.
This post originally appeared on servicevirtualization.com.