Posts Tagged ‘TDD’

Spreading The Way Announcing the Dojo in Bangalore!

Announcing the Dojo in Bangalore!

Emily Kaiser

Emily Kaiser

Head of Marketing @DellEMCDojo #CloudFoundry #OpenSource #TheWay #LeanPractices #DevOps #Empathy

It is with unbelievable excitement that we are officially announcing the opening of our third global branch with a Dell EMC Dojo in Bangalore! By sharing our DevOps and Xtreme programming culture, including but not exclusive to the practices of pair programming, test driven development and lean product development at scale, we have the deepest confidence that Bangalore is the geographical mecca that sets the tone of Digital Transformation we hope for in the larger company.

So what does this mean beyond the logistical rollercoaster that comes with opening a new office? Well, I’m glad you asked!

We are Hiring! Over the next few weeks, we will be rapidly and qualitatively (only because how else would we operate?) looking for and interviewing developers and product managers interested in becoming a part of this exciting new Dojo from its inception. So, if you know of anyone in the area that may be interested, please point them in the direction of Sarv Saravanan (sarv.saravanan@emc.com) who will be handling the process on the ground.

 

Otherwise, stay tuned on our team’s impending growth, engagement (both here and in India), and overall adventure!

Until next time…

 

TDD at the #EMCDojo Test Driven Development, Brian Roche Sr Dr Engineering

Test Driven Development, Brian Roche Sr Dr Engineering

Brian Roche

Brian Roche - Senior Director, Cloud Platform Team at Dell EMC. Brian Roche is the Leader of Dell EMC’s Cloud Platform Team. He is based in Cambridge, Massachusetts, USA at the #EMCDojo.

I work on a team where we practice pair programming and TDD every day. Pairing alone isn’t the key to our success, another important element is Test Driven Development or TDD.

Traditional Engineering Teams

Most engineering teams today, make changes to their code and often these changes break a whole bunch of ‘stuff’.  If you’re lucky, you find out which functionality was regressed prior to pushing code to production.  But more often than not, we’re not that lucky.  The breaking change isn’t caught because automation does not exist.  So the code gets into the hands of the customer long after it’s been written and results in an escalation.  This leads to frustration and increased customer dissatisfaction.  But it doesn’t just lead to frustration and inefficiencies for our customers, it results in Increased TCO for everybody involved.  The cost of working this way is ENORMOUS.

(more…)

Follow Us on Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.