Shine Theory / DevOps / Community

A podcast called The Allusionist (hosted by Helen Zaltzman) crossed my path that provided me with a light-bulb moment.

The podcast focuses on language and etymology. This particular episode contextualised that focus around a fantastic story with guests Aminatou Sow and Ann Friedman, talking about a term they had coined called Shine Theory (

Initially a private expression of comradery between friends, the term went big with the publication of this article in the New York Times written by Ann expounding on her newly adopted philosophy of “I don’t shine if you don’t shine” in the context of friendships and success for women.  It’s worth reading that article as well as listening to the podcast to see how far Shine Theory has come along since.  (Edit since writing: I just saw it referenced on the animated TV show American Dad which was weird).

To reiterate: “I don’t shine if you don’t shine”.

Shine Theory in brief is the philosophy of collaboration over competition.  

Such competition can manifest itself between direct peers, levels of a hierarchy and even between a company and its customers in an effort to position the former as a thought leader and the latter only as a consumer as opposed to a collaborator. 

For me, Shine Theory not only defines how success can be achieved across so many aspects of our lives but also brings clarity to the successes of such movements as DevOps.  The concept of collaboration of software development and operations, over the separation of role, knowledge and/or power is proving both an advantage and an enabler.

DevOps is more than a trend.  Its success has spawned some of the biggest changes in how software is created, maintained and discussed.  It represents the breaking down of silos and the sharing of responsibility to increase the velocity of development and quality of the result.  

The Open Source Community 

The open source community have always been a model of collaboration, embracing the theory that the many is more powerful than the few and that creation and innovation is fuelled by complete transparency.  It’s a beautiful thing that has flipped the traditional business model on its head.

Commercial companies like Rancher have demonstrated that keeping their source code behind closed doors is not a requirement for commercial success.  Adrian Goins, Rancher’s Director of Community, is a flag bearer for the movement with his latest community effort called Coffee and Cloud Native (CNCN).  Adrian (and WifeBot), driven by the tenets of Shine Theory, spend 30 minutes every morning informing a growing crowd about the latest and greatest in open source technologies often discovered only the night before through a combination of manual research and clever automation.

All technology companies do not embrace this behaviour however.  The tendency to perceive source code as critical intellectual property while ostensibly essential can be a poisoned chalice. 

There will always be algorithmic content that needs to be kept private to ensure a competitive edge. That is not in question.  That said, it would be a welcome change to see companies deciding early in their planning what needs to be private and what can and should be made public as part of the community.  

I once made an off-the-cuff remark in a public talk that, as much like you can judge the cleanliness of a restaurant’s kitchen by looking at its toilets, if you want to judge the quality of a software company, look at its open source.  While this isn’t the solitary foundation for a trustworthy vendor, it certainly does help.  

Conway’s Law

Conways Law is a regularly quoted warning, representative of what happens in the absence of Shine Theory. It states that “organisations design systems that mirror their own communication structure.”

Companies whose default practices revolve around value being derived from the hoarding of knowledge, property and power, risk a culture and product which may also reflect this.  The stifling of innovation and the isolation and frustration of their most valuable assets can be a result. Just read the Unicorn Project by Gene Kim for a great fictional, yet all too real example of this.  

Adopting Shine Theory isn’t easy.  It flies in the face of human nature.  We are selfish humans and we work hard for our achievements.  Arguments like job security, position and self doubt (what if I help somebody and they make me look bad by being better than me) are a perpetual psychological struggle.  Those thoughts often suppress the positive ethic of treating others as you want to be treated dating back to Confucianism and found in such modern phrases like “pay it forward” and “you get what you give”.  

Ubiquitous Security

My world is DevSecOps, an extension of the DevOps portmanteau in which Security is often seen as crashing the party of Development and Operations like an overbearing friend squeezing into an intimate conversation.  In spite of mixed perceptions of what DevSecOps means, its intent is noble.   That, much like safety plays an integral part in the processes, people and technologies of more mature industries, security will find its way as a natural progression of DevOps.  So much so that a unique expression is no longer required.  There will be a future where security is a ubiquitous element of the software creation process.

While we are not there yet, I look to demonstrable innovations and collaborations within the open source community as a lighthouse in a storm and seek to continue to help others, both individuals or organisations, bring the education, transparency and community that Shine Theory represents as a fuel for innovation, imagination, and mutually assured success. 

The post Shine Theory / DevOps / Community appeared first on Codifyre.

*** This is a Security Bloggers Network syndicated blog from Codifyre authored by Stephen Giguere. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)