If you think on-prem vs off-prem is a deciding factor, you were probably born before 1995. It is the functionality of the service that matters, not the location of the bits.
I write this while snacking on free banana chips I obtained from the lunchroom. A week in the Dojo is very different than a week programming at home or in a cube farm, and it has as much or more to do with culture than tools and process.
The EMC Dojo in Cambridge, MA (https://www.cloudfoundry.org/welcome-to-the-emc-dojo/) is a place that contributes code to the open source cloud foundry project using a specific development methodology built around pair programming, test driven development, and lean development, known as “the way”. They also teach the way to anyone interested in contributing to Cloud Foundry as well as other development teams within EMC. They earn the title of Dojo by literally being a “place of the way” .
From the moment I got there, I was a member of the team. I had planned to work in the same area, quietly observing the way while working on my own projects. That didn’t work out, and I’m so thankful it didn’t. On the first day, everyone in the Dojo had introduced themselves to me and were interested in what I was working on. They adopted my story into their backlog and encouraged me to attend their standup the next day and begin pair programming with them. I felt so valued before I had even added value. Before long I found myself pair programming on a PHP app (I have no experience in PHP) and doing anything I could to contribute.
They went to lunch together every day I was there, often participating in an office wide Yoga lunch or Go Programming Book Club. They cared about each other’s quality of life and personal hobbies. They struggled out loud with programming syntax and architectural design choices and often came together to discuss, solve, or vote. Every member of the team was heard and had the same weight in decision-making.
And it works. The speed and efficiency that they are able to take a story idea and turn it in to working code is amazing. And although they are all individually quite talented, there seems to be a “greater than the sum of their parts” thing happing with “the way”. They are completed unfazed by tackling something new largely because of their confidence that as a team they will be able to solve it.
What I witnessed, no, what I was a part of for my week, was a team of developers effectively coding for hours based on shared goals and methodology in an environment that made everyone happy. I’m so thankful to everyone who paired with me, shared with me, challenged debated and listened to me, welcomed me, and taught me.
What an outsider might notice first is the ping-pong table next to the cafeteria with available food and no checkout register, but that would be missing the point. The culture that they have built here and the benefits of developing in “the way” have left me with a lot more than this now empty bag of banana chips.
There was a time when the first software developers (Dev) and early “computer” operators (Ops) where the same person. Or at least, on the same team. They certainly ate in the same lunchroom.
Next came period of software development companies. Most “real” applications were written by software vendors and sold to businesses to run. Dev and Ops no longer worked at the same company and in recent years, thanks to globalization, could be half way around the world from each other.
More recently, there has been a new business digitization happening powered by the desire for a more digital consumer interaction. Many of these small custom apps are written in house. Dev and Ops are once again reunited.
Simultaneously, however, the rise of public cloud services has caused many companies to outsource their IT infrastructure and therefore their operations team. This time it is Ops turn to go globetrotting while Dev stays at home with the business.
One wonders, are Dev and Ops simply star-crossed lovers who are destined to pass as ships in the night, or are they destined to join together as DevOps and live happily ever after?
So I finally read The Phoenix Project. It was recommend to me enough times that I just broke down and did it. I’ll skip a review for now.
One aha moment I had related to keeping a production environment in sync with the various non-production environments. I knew it was tricky. I knew it was important. But it always seemed like a problem that was destined to be tricky and error prone. But I didn’t completely understand why.
The book used an example of a manufacturing factory floor and how you don’t want to see work flowing backwards (upstream) but you definitely don’t want to design a system with loops. For manufacturing, you start with raw goods and move them on a single flow through various work centers until you have a finished product.
Which of these do you think is more likely to be successful? The way most people do it (fig 1.) or having an immutable production environment (fig 2.) ?
Time for a new blog. The world needs another blog, right?
I’ve had a blog for a long time (see here: http://ajax.verkley.com/blog/brian/) based on software that I wrote eons ago. It is ancient. And it was mostly used for personal stuff only immediate family and friends would find interesting. I use Facebook for that purpose now, which is why that blog is kinda dead. That is not this.
I thought I’d like a place that I can publish my technology and business thoughts. There are a lot of people on my Facebook feed that would love to see pictures of my kids, but couldn’t care less if I thought Linux containers were cool or not. So, different content, different audience, different medium.
My sister Lisa works for Automattic (the company behind WordPress) and she’s awesome, so I can only assume WordPress will be too. Wish me luck.