Welcome to the EMC Dojo!

The EMC Cloud Foundry Dojo is officially opening today! To learn a bit more about EMC’s Dojo, we brought in Victor Fong, the Engineering Director of EMC Cambridge Dojo and Cloud Platform Team, as well as Megan, a Dojo software engineer.

How did you get started with Cloud Foundry? 

Megan: I was a developer at EMC working on Atmos and ViPR ECS. When I heard about the Cloud Foundry EMC dojo, I was immediately intrigued to contribute to the best PaaS in the industry.

Victor: Before joining EMC, I was an engineering director of a legacy Java Enterprise Application in a traditional technology company. When I first entered the Cloud Foundry Dojo in San Francisco, I was deeply impressed with the passion and energy that each person shared. The unique opportunity of starting a dojo from scratch in Cambridge, to work on the newest and coolest software platform, was an offer I could not refuse.

EMC is opening a Cloud Foundry Dojo. What is a Dojo?

Victor: The word dojo means several things that reflect what the EMC Cloud Foundry Dojo is all about.

• Dojo means place of the way.
• The way at the dojo means the way that we write code – pair programming, lean development, contributing to open source Cloud Foundry.
• And we teach others ‘the way’ so that they too can become contributors.

Did you get your start on Cloud Foundry through a Dojo?

Victor: Yes. When I first joined the EMC team, I traveled to San Francisco for 6 weeks to go through the Dojo program. Before starting Dojo, I intentionally did not learn any of the languages and technologies involved in Cloud Foundry or the program, so I could experience firsthand the dojo’s effectiveness. When I first got there, I did not know Ruby or Go, the building block languages of Cloud Foundry. The first two days of pair programming was exhausting, as it was a completely new working environment, new code base, new technology, and new programming language.

“Trust the program” I was told. And all of a sudden, on the third day I felt productive and was truly contributing. By constantly pairing with a more experienced engineer and getting my hands dirty, I was able to learn the ins-and-outs and best practices quickly. The rest of my Dojo time flew by quickly and I was constantly learning every day. By the end, I was able to take a backlog story by myself. I was ready to pair with new engineers and show them the new “way”.

Megan: I too started at the San Francisco Dojo. I started with the Cloud Platform Team in June and attended the CF Dojo in San Francisco. The experience was great. My time was split between working on Bosh and the Bosh CPI over 6 weeks. I worked with two great teams that really work well together and got to learn about pair programming and test driven development. What was most surprising to me was how quickly the team could work while still maintaining quality and a fun, friendly environment. Every team member is involved in decision making and planning and the plan and design are constantly evolving, so it’s an exciting way to work.

This was also my first experience doing open source development. While it still feels strange to be able to share my commits on Github, it’s also been pretty fun.

What are you most looking forward to with this new EMC Cloud Foundry Dojo?

Victor: I look forward to a wider adoption of Cloud Foundry and a higher participant rate from the community into Cloud Foundry.

Megan: I’m most looking forward to growing our team and continuing to work on Cloud Foundry and Bosh with the skills that we picked up in San Francisco, spreading the culture throughout EMC. So far, our team has meshed well together, and I’m looking forward to being able to share this with other teams.

What has your experience been like working in the dojo?

Megan: So far, working in the Cambridge dojo has been a ton of fun. We’ve tried to take our experience from San Francisco and replicate it in Cambridge. Both the office and the team have been constantly growing and changing and it’s been cool to be a part of it from the ground up.

Victor: Three things stand out for me: pair programming, test driven development and continuous innovation.

Pair Programming. Through pair programming, each developer can quickly gain context in a strange code base. By doing constant rotation, each developer can learn and own the entire code base, instead of each individual developer owning a small section of it as in other traditional teams.

I find that my daily work is more productive because with another engineer constantly watching over, the error rate is a lot smaller. This “Archon” mode turns two engineers into an ultra-productive mini-team by removing other distractions, such as email, phone, social media websites, etc. Developers are also much more likely to follow best practices such as test driven development.

Test Driven Development. In the previous enterprise application that I used to manage, QA was a major headache because of the manual testing and the amount of time and effort each QA cycle needed. New features were often stuck in the QA cycle for months before reaching customers. Developers were also more inclined to create unstable code because they would rely on QA engineers as a safety net. As a result, the feedback cycle for developers would take days if not weeks.

In our dojo, we don’t have QA engineers. Each developer is responsible for creating and automating the unit, integration, and end-to-end test cases. We have testability built into our products. We follow a strict guideline of developing and testing. If a new feature cannot be automatically tested, then the feature is not accepted. With this practice, the feedback cycle for bugs and malfunctions becomes almost immediate. Team velocity and productivity are so much greater than traditional practices.

From Continuous Integration to Continuous Innovation. By doing test driven development, we remove any human intervention from the time it takes to release the feature. It’s not uncommon for our continuous integration pipeline to produce multiple software releases on a single day.

With this model, product managers deliver features and quickly gather customer feedback to determine the next features to develop. In the “Old World”, features would take months, if not years, to reach customers. In our “New World”, development is much more agile and the feedback cycle is quick.

What does it feel like to live and work in this new world?

Megan: I think probably the biggest change is the speed at which everything is evolving. Projects move faster and technologies change constantly. One of the benefits of going through the Dojo was learning how to pick up stories and technologies without much context, through pairing and rotation. This skill has made it much easier to jump into unfamiliar territory.

What do you think is so important about the dojo?

Victor: The dojo is all about showing developers and organizations the “way” to develop software. Adapting to the “way” will make developers and organizations move a lot faster and gain a competitive edge in this ever-quickening world.