In my previously-written article “Concurrent Engineering: The Foundation of DevOps” I wrote “just because you use puppet does not necessarily mean your organization is practicing DevOps.” I didn’t spend much time on it then, but I think it bears repeating and further explanation. The DevOps “movement” has seen, and will likely continue to see, a huge influx of new tools as organizations attempt to find ways to adopt DevOps within their organizations. These tools have included (and certainly have not been limited to) tools that aid in monitoring (statsd), configuration management (puppet), and continuous delivery (hubot).
Operations engineers, software developers, and managers are in a mad dash to develop, utilize, and integrate these tools within their organizations. And that’s where we’re going wrong; we are focused on a single component of the Software/Systems Engineering Process. This process model contains three main components that are central to its existence: methodologies, techniques, and tools (Valacich 2009). While I don’t need to go into each one specifically, it’s clear that the tools are just a single factor in the overall process. Following the model further, it becomes clear that the makeup of each of these components influences the other components in the process.
Put simply, DevOps is a methodology and, as such, it’s natural that we’re seeing a huge response in tools. What I feel we’re missing, however, is more information about the different techniques used throughout organizations in their software and operations engineering processes. An excellent example of this is Scott Chacon’s explanation of how Github uses Git (and Github!) to deliver continuous improvement to their service. With that said, I would like to see more organizations refine their techniques and talk about these as much as they talk about their tools.
Year-End and New-Year Updates
Happy New Years, everyone.
I thought I’d ring in the new year with some site stats from 2011.
- Only 10 posts published.
- 59,238 pageviews.
- 24,829 visitors (22,634 unique)
- 1.32% bounce rate.
- Multiple job and business opportunities in direct response to articles I wrote including a new job (more details below).
I really want to write more. My resolution then is to “write more.” Using a more quantified approach, I will spend at least 30 minutes a day writing for at least five days a week. That doesn’t mean I will publish five articles a week. One of my big issues with writing is the amount of time that goes into each post. I approach my writing very academically and try to back up my ideas with citations; this research takes time. I also, very frequently, solicit feedback from other people before publishing. But I really enjoy writing and I really enjoy receiving feedback on my ideas through this blog so I would like to continue doing it.
Other resolutions of mine include physical health and professional development (I’d really like to give a talk at a conference this year).
I also have some really exciting news. Starting on Monday I will officially begin my employment with dotCloud on their Site Reliability Engineering team! This is exciting for two reasons.
First, working at dotCloud is going to be an awesome experience. Everyone I’ve talked to is incredibly smart. Our CEO, Solomon Hykes, was also just named on Forbes’ “30 Under 30” list. Third, and probably most importantly, is that I’m going to absolutely love the work. I love solving problems, particularly in devops, and I love writing tools that make people’s lives easier (which is precisely what dotCloud does). If you’re looking for a Platform as a Service provider, try out dotCloud and let us know how you like it.
The second reason this is exciting because, in the process of starting at a new company, I’ve managed to expand my personal consulting practice. I don’t think I’ve said so before, but I provide systems engineering services to Loud3r Inc. I’m their only “web ops” guy and we’ve managed to completely turn things around in the past 6 months; we’re providing our services better (more reliable, more frequent updates), faster, and cheaper than before. Rather than cancel the contract entirely, the CEO of Loud3r and I felt it was a good idea for me to subcontract a large portion of my workload to a trusted colleague of mine.
How about you? Is there anything exciting you would like to share about the progress you made during 2011 or large changes you’re making in the start of 2012? Tell me all about it!
DevOps is all about trying to avoid that epic failure and working smarter and more efficiently at the same time. It is a framework of ideas and principles designed to foster cooperation, learning and coordination between development and operational groups. In a DevOps environment, developers and sysadmins build relationships, processes, and tools that allow them to better interact and ultimately better service the customer (James Turnbull).
At the time of writing, if you were to search for “devops” you would find eight results attempting to explain what devops is, one result for a conference, and one rather satirical article (although not necessarily incorrect) where the author answers the question of “how do you implement devops” with “nobody seems to know” (Ted Dziuba).
The big problem with the DevOps “movement” is that we essentially have a bunch of operations and development people promoting it and trying to implement it within their organizations. Meanwhile, those with management and business responsibilities, even if explained the “what,” don’t understand the “how.” Just because you use puppet does not necessarily mean your organization is practicing DevOps.
This shortcoming is the result of us devops proponents either falsely claiming these techniques and methodologies are new or not knowing any better. If we had something more relatable for the business people (and, by principle, we should be business-oriented, too) then I think DevOps would have more of a chance.
Well, get your product and management together because the truth is that DevOps is actually a form of Concurrent Engineering.
Concurrent Engineering (CE) is a systematic approach to integrated product development that emphasizes the response to customer expectations. It embodies team values of co-operation, trust and sharing in such a manner that decision making is by consensus, involving all perspectives in parallel, from the beginning of the product life-cycle (ESA – Concurrent Engineering Facility).
Concurrent Engineering encompasses several major principles which just so happen to fit the definition (however formal or informal) of devops.
I’ll list them from the Synthesis Coalition here:
- Get a strong commitment from senior management.
- Establish unified project goals and a clear business mission.
- Develop a detailed plan early in the process.
- Continually review your progress and revise your plan.
- Develop project leaders that have an overall vision of the project and goals.
- Analyze your market and know your customers.
- Suppress individualism and foster a team concept.
- Establish and cultivate cross-functional integration and collaboration.
- Break project into its natural phases.
- Develop metrics.
- Set milestones throughout the development process.
- Collectively work on all parts of project.
- Reduce costs and time to market.
- Complete tasks in parallel.
I wrote a blog post this week on how engineers or “technical people” don’t have to, and shouldn’t, be jerks. My argument was that the stereotype that technically-minded people are bad at social skills was just that, a stereotype, and that employers should stop allowing us to get away with it. I knew it was going to be controversial when I wrote it, especially because the type of people who find my blog (HackerNewsers) are usually technically-minded people (with a nod to the rest of you entrepreneurs, biz, and VC folk). As expected, a large chunk of commentors (both on HN and on my blog) disagreed with my argument and a large chunk agreed.
What I did not expect, however, was to be misunderstood so severely that I would be accused of wanting to ruin the lives of those who are “psychologically incapable” of learning social skills. One commentor posted a picture of a child with autism and accused me of trying to make him a second-class, unemployable citizen. Another commentor went as far as to paint a grisly picture of these “psychologically incapable” people committing suicide – all because of me.
This blog is set up in such a way that I must manually approve comments from first-time commentors. This means that I have read every comment that was posted to my article (a few people posted more than once, but I read those too) before they appeared on my blog. I approved the comments despite the fact that I found them extremely upsetting because, even though this is my blog, I felt that everyone deserved to be heard.
I want to take the opportunity to say that I think this combination of hypersensitivity and political correctness is an awful thing. It’s OK to be offended, but I feel that very often the thing that offends us is a misunderstanding. In this case, my point was that engineers shouldn’t be jerks and should instead learn some social skills so they can interact more effectively with co-workers and clients but it was misunderstood as if you’re bad at social skills, even if you can’t help it, then you should be treated like garbage. I don’t think that bloggers should have to acknowledge every exception to the points they make or write disclaimers into each of their posts – that kind of defeats the point (which I feel is free speech on a massive scale, by the way).
So please, the next time you feel offended, consider asking the offender for clarification before you react. You might save yourself, and them, from a lot of unnecessary heartache.
As a technical person who has worked many customer-facing support roles, I’m offended by the often-cited notion that technical people have poor people skills or are poor at filling customer support roles. Earlier this week, a web host incited a Public Relations nightmare when their “Technical Director” responded childishly to some customers, disabled their accounts, and deleted their backups. The company’s response was to create a new customer support position so they could keep their Technical Director yet isolate him from their customers. In this new customer support personnel’s recap of the situation, he wrote:Jules [is] the Technical Director. Jules does a fantastic job looking after things and keeping the infrastructure running well. Unfortunately though, as is often the case with very technically minded people, customer service is not always his strong point.
- The understanding that they represent their employer and that people are relying on them,
- A compassionate, helpful, and courteous attitude,
- The knowledge of whatever they’re supporting.
