Daily Archives: February 14, 2013

Title: DevOps – A Valentine’s Day Fairy Tale

This post is a guest blog post authored by Matt Watson, CEO of Stackify

Once upon a time two people from different sides of the tracks met and fell in love. Never before had the two people found another person who so perfectly complemented them. Society tried to keep them apart – “It’s just not how things are done,” they’d say. But times were changing, and this sort of pairing was becoming more socially acceptable.

They met at the perfect time.

Ops had grown tired of the day to day grind of solving other people’s problems. Enough was enough and she needed a change in her life. A perfectionist and taskmaster to the highest degree, she tended to be very controlling and possessive in relationships. It became more about commands than conversation, making life miserable for both parties. She began to realize she hated change, and felt like she spent most of her time saying “No.” It was time to open up and begin to share to make a relationship work.

Dev, on the other hand, was beginning to mature (a little late in the game, as guys seem to) and trying to find some direction. He had grown tired of communication breakdowns in relationships – angry phone calls in the middle of the night, playing the blame game, and his inability to meet halfway on anything. He began to realize most of those angry phone calls came as a result of making impulsive decisions without considering how they would impact others. His bad decisions commonly led to performance problems and created a mess for his partners. Dev wanted to more actively seek out everything that makes a healthy relationship work.

The timing was right for a match made in heaven. Dev and Ops openly working and living side by side to make sure both contributed equally to making their relationship work. Ops realized she didn’t have to be so controlling if she and Dev could build trust between one another. Dev realized that he caused fewer fights if he involved Ops in decisions about the future, since those decisions impacted both of them. It was a growing process that caused a lot of rapid and sudden change. Although, like most relationships, they knew it was important to not move too fast, no matter how good it felt.

Dev and Ops dated for about four years before they decided to get married. Now they will be living together and sharing so much more; will their relationship last? How will it need to change to support the additional closeness? But they aren’t worried, they know it is true love and will do whatever it takes to make it work. Relationships are always hard, and they know they can solve most of their problems with a reboot, hotfix, or patch cable.

Will you accept their forbidden love?
7 Reasons the DevOps Relationship is Built to Last

Faster development and deployment cycles (but don’t move too fast!)

Stronger and more flexible automation with deployment task repeatability

Lowers the risk and stress of a product deployment by making development more iterative, so small changes are made all the time instead of large changes every so often

Improves interaction and communication between the two parties to keep both sides in the loop and active

Aids in standardizing all development environments

DevOps dramatically simplifies application support because everyone has a better view of the big picture.

Improves application testing and troubleshooting

————————————–

About the author: Matt Watson is the Founder & CEO of Stackify. He has a lot of experience managing high growth and complex technology projects. He is on a mission to simplify the daily lives of developers and how they support their production applications by leveraging DevOps.

This is a second annotation of an article, Send in the Tech Reinforcements authored by Arthur Herman and John Scott. We’re focusing here on the authors’ point that “the Pentagon relies on a bureaucratic review process that demands contractors anticipate and resolve problems in advance. Every software engineer, however, knows that’s not possible or even desirabled.” (quoted from Messrs Herman and Scott’s article, a link to which has been provided in this paragraph). We are also interested in a comment made further on in the article that “[l]earning by trial and error doesn’t work so well for aircraft carriers or Abrams tanks, but it is crucial for the development of effective software.” (ibid).

We think that the Pentagon process that’s got our authors’ attention, which they find hard to accomodate, is actually operational risk management for software development. In our opinion, the interest on the part of the Pentagon in implementing and exercising operational risk management in order to ” . . . anticipate and resolve problems in advance” is far more than merely a “bureaucratic review process”. (quotes are excerpted from the Messrs. Herman and Scott’s article). In fact, we think it is critically important for the welfare of our military personnel that this type of scrutiny be exercised over custom requirements for software. Regardless of whether specific software is intended for office computing use, or for use on the battlefield, any software application accessed by today’s desktop computers is potentially a trojan horse that could be maliciously exploited by enemies of our country or other individuals with nefarious intent.

To give the authors credit, perhaps their point is that the operational risk management methodology implemented by the Pentagon is ineffectual. If, in fact, the authors are attempting to make just such a point, then, perhaps we can be more agreeable to their point of view. However, by no means do we see how the Pentagon could safely adopt a policy that welcomes a “learning by trial and error” method of software development and still safeguard our military personnel.

Rather, we agree with the authors that attempts at managing the risk represented by custom software have been, evidently, somewhat clumsy on the part of the Pentagon, and, further, ineffectual as regards safeguarding our systems from malicious attack, despite substantial cost overruns. But we think all of this work and little progress points to a real need to rethink operational risk management policies and procedures for the actual task of developing software for military use in 2013. By no means, in our opinion, does it make sense to abandon the attempt altogether.

In the next post to this blog we will look at one last set of points made in this article.