DevOps Zone is brought to you in partnership with:

Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 84 posts at DZone. You can read more from them at their website. View Full User Profile

4 Signposts Towards a DevOps-Friendly SDLC

  • submit to reddit

In last week’s “DevOps Imperative” webcast, I mentioned that DevOps is more directional than prescriptive. I mentioned that the key directions to follow were to push towards more collaboration and automation to enable your team to deliver more frequently with less risk.

Four of the principals and laws we cite most frequently in white papers and webcasts can help reinforce this direction and provide some needed checks as you begin transforming towards an organization whose path from idea to value (the software development lifecycle or SDLC in stodgy terms) needs to be more DevOps friendly.

Conway’s Law

What it is: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations”

Why you should care: Conway’s law points out that when we design some solution, and we put three teams on the project, the solution will likely have three sub-systems and the interaction of those systems will reflect how well the three teams communication. This is a clear warning to organizations that are trying to solve problems that span silos. Their solution quality will be bound to the ability of the silo’d teams to communicate with each other.

Often, communication and collaboration must be improved as a pre-requisite to other solutions. Any tool or process that you put in place that improves visibility and communication across silos will help future problem solving.

Read more: Conway’s Law on Wikipedia

Dude’s Law

What it is: Dude’s law is modeled on Ohm’s law which states that current equals voltage divided by resistance. Dude’s law states that the flow of Value = Why / How.

Why you care: How we get stuff done is important. In a circuit, we need conductors to move power from point A to B. But we should try to streamline the path and lower the resistance in it. Focusing on the “Why” and trimming out extra resistance to getting there is key.

Teams go wrong here in different ways. Sometimes, Why is over-emphasized – especially when it comes to audit and slow, painful processes are put in place. The How needs to improve there. We also see badly run Lean initiatives optimizing the How of dumb processes. We really need to pay attention to both Why and How to maximize the flow of Value.

When adjusting an SDLC process, start with a deep analysis of Why something needs to be done. I recommend the 5 Why’s technique.  Only once you really understand the root needs, can you tackle how the team can meet the need with the right low resistance process.

Read more: Original blog post from the Dude (David Hussman of DevJam)

Reuse/Reuse Equivalence Principal (REP)

What it is: “The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused.” Robert C. Martin’s C++ Report (1996)

Why you care: This principal has long explained good software reuse – it’s better to build libraries and know what version of a library we’re using than to copy code from project A to B. Today, we can apply the same principals to configuration (we should know that Tomcat Server A is using server.xml configuration version 12) as well as infrastructure – we should know the version of the image of the VM that server is running on.

Many DevOps afficionados reccommend storing all your stuff in an source control repository. This is on the right track. Everything that goes out should be versioned. An SCM is the right place for source code, and an OK place for some other items. A package repository is better. We’ll be talking more about binary/artifact/package repositories in an upcoming webcast.

Read more: Reuse maturity model


People Tend to Inconsistency

What it is: This is a key observation from Alister’s Cockburn’s review of people and how they impact software development. While people are good at taking initiative and problem solving, they “…tend to inconsistency. The prediction is that methodologies requiring disciplined consistency are fragile in practice.”

Why you care: When working on any process in the SDLC, you should have a grave distrust for anyone who is required to do things correctly. The more things they have to do correctly, the worse the “smell” of the process. A manual deployment process with dozens of steps? Run from that screaming. Likewise, having Test engineers run through detailed test cases repeatedly is not a promising strategy. Tasks which must be executed precisely according to a script (boring tasks) should be delegated to machines, while people work on creative problem solving.

Read more: Characterizing People as non-linear first order components in software development.

Published at DZone with permission of Eric Minick, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Matt Watson replied on Wed, 2012/08/29 - 8:46pm

The problem with SDLC is the application support part of the lifecycle is broken. Agile development has caused rapid change in applications and rapid change inevitabely creates a rapid amount of software bugs. The problem is in most companies developers do not have access to their applications or production servers. This makes fixing those applications bugs really difficult and time consuming. A lot of companies have 10-20 developers for every system admin they have. But the developers are hand cuffed when it comes to production application support.

My company Stackify has a new DevOps service that is designed to solve this problem.  We can give the developers more visibility in to their applications and production servers. We provide the safe and secure read only access they need. Now they can do simple things like see log files, config files, tracking app changes, server monitoring, application monitoring, etc. Check out our website to learn more. Basically we have invented Devops support and we solve a big issue in the SDLC for most agile development teams.

Eric Minick replied on Thu, 2012/08/30 - 9:01am in response to: Matt Watson

Good stuff Matt!

I think talking about "the problem" with SDLCs is optimistic, but we're big believers in closing that Dev / Ops gap as well.

A related issue in a lot of enterprises is the "project" view where you deliver some functionality and then roll off to another project. I think they need to adopt more of the "product" view where the same team that built the stuff, receives the monitoring and feedback to fix it. Knowing that you have to maintain something and own it in production can nudge the development team towards higher initial quality a little bit.  

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.