Everything's code, 'zero tolerance for assholes': Yup, it's ChefConf ChefConf 2015 took place last week in Santa Clara, with around 1500 attendees focusing on DevOps using Chef software to automate infrastructure configuration and application deployment. What is DevOps? Defining it is a struggle, according to Chef CTO Adam Jacob who devoted a large part of his entertaining keynote to the …
This post has been deleted by its author
How does a certain Linux kernel lead fit into that position? He seems to pride himself on being one.
You have to distinguish between Dilbert-type arseholes and the other arseholes.
Also
If you consider the large enterprise, you have policy implemented across a variety of tools. What changes things is the ability to express those controls in a formal way using Chef. That policy as code also comes back into Chef Delivery
Don't tell me logic programming is back en vogue? That would be rad!
...except "zero tolerance for assholes" is basically meaningless without a precise definition of what constitutes one. From "causing friction for the hell of it and/or simply not liking the muppet next to you" to "causing friction due to not being a mindless yes-drone and having an opinion of your own" to "not taking well to idiots insisting on unequivocally idiotic things" to "anyone who dares talk back to me, God-emperor of this wretched bunch of minions" there is a lot of room for the fragile ego of the one making the judgement call. Teamwork is necessary, sure, but also immensely overrated in a huggy-feely way these days.
Asshole does have a very specific definition, taken from Robert Sutton's "The No Asshole Rule" book.
Two tests are specified for recognition of the asshole:
1. After encountering the person, do people feel oppressed, humiliated or otherwise worse about themselves?
2. Does the person target people who are less powerful than him/her?
http://en.wikipedia.org/wiki/The_No_Asshole_Rule
This post has been deleted by its author
...except "zero tolerance for assholes" is basically meaningless without a precise definition of what constitutes one.
But, for many, you must include the term manglement in front of asshole and then you clarify the definition.
On another note, hey ElReg, how about a "manglement asshole" icon. You COULD use a picture of one of the more enduring assholes of the last 25 years - Steve Ballmer, (others might recommend Steve Jobs instead) as a starting point.
I agree with the general discussion as far as automating deployment, but the comment about personality is dead wrong.
Google "Steve Jobs asshole" or "Torvalds asshole" and then try that with the other names at this conference and you will discover something interesting - the ones that get called that the most are some of the iconic forces of our industry.
It's easy to call someone an asshole.
What is NOT easy, however, is to take a clear, technically consistent vision and apply it in our reality without compromise. When someone does this, eventually they have to push other ideas aside, and as ideas are our personal creations, it hurts when this happens to ours, so our natural reaction is to attack the creator of the superior idea at the personal level.
The software industry will never improve until it can subsume ego and be able to rationally consider other ideas and accept them if they are superior, or decline them if they are not, without resorting to name calling and other childish behavior.
Engineering by consensus works only with enlightened leadership - hence the term benevolent dictator. Consensus by itself is insufficient and results only bureaucratic software.
The win is MS showing up and promoting their own tool set. DCS is not something I've played with, but certainly seems easy to implement and program for in Windows platforms from the examples I've seen.
Fail is chef for Windows. I worked at a shop that spent 3 years trying to get it to work. All it created was headache and longer deployments than if we had simply copied the updated code manually and edited config files. Hell, a simple batch job would have done it.
The driving force for this direction was a pointy headed boss who had a strong Linux/development background and little to no experience in the Windows/.Net world. The thinking was all wrong and caused all sorts of problems, and friction with the operations team. Advice was never listened to until it was too late and then blame was shifted. Ultimately, it led to me being let go due to "not being on board". Call it what you wan't but if it affects production systems and our customers user experience, you can bet your ass that I'm going to ask tough questions and raise alarms.
They are still trying to make it work and said pointy haird boss is still at the helm. And frustrations are still there...
In order for Dev/Ops to really work, both sides have to be on board and actually willing to listen to the other team. Devs know dev but it is surprising to me how little they understand the systems/infrastructure that are used to present their wares. Having an open dialog and not just one team lording over the other is essential to success for the business. Oh, and software sprints are great for a development team but are absolute garbage for Ops. :)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
