Archive for the ‘Meetups’ Category

Dell EMC Dojo at Hopkinton! Reviewing what we covered, and what we learned

Reviewing what we covered, and what we learned

Hey again everyone! We’re writing out today to talk about a few topics that we covered during our time at the Dell EMC Dojo Days in Hopkinton. We met with a lot of great minds and took plenty of input into how we work. We also gave a lot of insight to passersby in what we did and how we worked.

Firstly, Brain Roche and Megan Murawski debuted the famous “Transformation Talk”. We normally give this presentation in preparation for an engagement with another team, but in this case, it was given to allow open criticism and circulation of our methodology to the rest of the company. We cover in this presentation: pairing, and why it’s important to our process, why we use TDD (Test Driven Development) (and why you should too!), and our weekly meetings including Retros, IPM, and Feedback to name a few. We had plenty of great ideas and questions, as usual, and we realized twenty minutes over time that we couldn’t get Brian off the stage.

Xuebin He eventually got Brian off-stage for a talk he conducted on CICD (Continuous Integration, and Continuous Deployment). Xuebin being one of the developers at the Dojo allowed him to be a bit more technical in his talk, and cover some of the programming practices and tools we use to achieve this at the Dojo. Concourse is our tool for running our beautifully constructed tests, along with standard mocking design patterns and the code quality produced with TDD.

We picked up again on Tuesday at 1145 to talk about why a PaaS exists, and why it’s important. That talk, given by yours truly, was focused on some of the common technical roadblocks that keep developers, customers, and managers from being able to work efficiently; as well as the ways using a PaaS can solve those problems to build a better business.

To containerize applications for a PaaS, we would need to learn basics like “What is a 12 factor application, and what’s a container?” Thinh Nguyen stepped in and gave a great description on how we use guiding principles while developing our application environment to be better for us and our customers.

Throughout all of our talks, we worked away on two pair stations very carefully brought from our lair in Cambridge. We gave away some free swag, some free candy, and raffled off some super giveaways. We thank everyone involved in preparing and executing these few days for their hard work. We also want to give a huge thanks to everyone who attended our talks (rambles) and participated in some mind-expanding conversations.

Finally, I want to close with a few notes. We always enjoy fresh perspective. If you had more to say, or you missed us during our time and you want to start a conversation, leave a comment in the comment section! If you don’t want to comment here, then drop us a line in my email. We’d love to hear from you.

Until next time, remember: Cloud Foundry, Open Source, The Way. #DellEMCDojo.

Bringing Cloud Foundry to You… Exciting Upcoming Events that the Cool Kids are Attending

Exciting Upcoming Events that the Cool Kids are Attending

Emily Kaiser

Emily Kaiser

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

For those of you who follow us on Twitter (@DellEMCDojo for those that don’t) or via this blog, I would guess it is pretty evident that we just love Cloud Foundry. We take pride in being a member of the foundation mostly because it is with this platform that we feel we are delivering and practicing what we preach; living out a true DevOps culture most conducive to productivity and quality product and delivery.

We are lucky enough to just be returning from Cloud Foundry Summit where upwards of 800 developers and other market adopters joined in Frankfurt, Germany to learn from other community members and to be a part of the PaaS’s business direction. With the Native Hybrid Cloud team, we at the Dojo spent our days representing DellEMC through presentations and booth shifts. We left feeling even more confident in our daily choice to use Cloud Foundry and to further evangelize the PaaS for the betterment of the larger technical OS community.

It is because of this that we are excited to announce that we will be hosting and supporting three Cloud Foundry Days here in the near future. Cloud Foundry Days are new, one-day educational events aimed at developers and operators who want to connect with businesses, learn about the platform, and share knowledge. The first that we will be hosting with the support of TIBCO, Pivotal, Telstra, Stark & Wayne, among others, is going to be taking place on October 18th in Sydney, Australia. If you have any interest in attending or know of others who may be, please find the registration link here: The second of these events will be taking place on October 20th in Melbourne, Australia and will also be supported by TIBCO, Pivotal, Telstra, Stark & Wayne, among others. The registration link for this event can be found here: Last, but definitely not least, is the CF Day in Shanghai, China on October 25th where we will be supporting GE (Registration information to be available within the next day or two. Please contact us via twitter if you are interested).

We truly hope that these events will be fruitful in their reach and effectiveness, and help our technical community discern the best option for themselves and the businesses they affect. Teamwork makes the dream work!

What If We Do A Little Less: Watch Dan Ward & The Simplicity Cycle #EMCDojo Meetup with Agile Expert and Author

#EMCDojo Meetup with Agile Expert and Author

“Simplicity is not the point, the point is not to reduce complexity. Goodness is the point. Goodness and value.”


Last week we were lucky enough to have Dan Ward come to the #EMCDojo to discuss the principles of his new book The Simplicity Cycle: A Field Guide to Making Things Better Without Making Them Worse. Watch the meetup below! If you don’t have time to watch right this second, read the Q&A for a teaser.



Q: How do you sort through customers’ different definitions of simplicity? Isn’t on customer’s complexity another customer’s value?


A: Different customers are going to have different definitions of goodness. Different customers will also have different levels of tolerance for complexity. For some customers, a certain level of complexity makes it less good and hard to use. for a super user, that same level of complexity is still okay. So part of the challenge is to understand with a large user community what goodness means. How do we mitigate that when you have users that want a lot of complexity and users that tolerate complexity less well? When you optimize a tool for the least capable user you improve its performance for all the users, including the most capable users. Simple tools tend to outperform their specs. Simple tools satisfy a broader range of interests and user sets than the designers and engineers might have anticipated. Simpler approaches tend to satisfy a broader range of users and customers. Which isn’t to say we shouldn’t provide a more complicated alternative for those users who want it – for whom goodness and complexity are directly proportional. And you only find that out if you’re engaged with your customers to get a sense of how they value complexity/simplicity. You have to talk to your customers to figure out what goodness means for them.

Q: What about modularity?


A: Modularity is a great strategy for mitigating and managing complexity. A modular design is one where you can plug and play, and let the users plug and play simpler or more complex modules. A modular design approach gives your users that optionality, the chance to engage and customize without complexifying things for those simpler users. Modularity is a simplifier and a goodifier. It improves the quality and flexibility of your design, but makes it robustly flexible. Complexity tends to increase fragility, and modularity is a way to combat that. 


Q: What about machine learning and AI? Does it change the vector position on the goodness and complexity graph?


A: Automation and machine learning take some of the burden of processing complexity from that user, and puts it below the screen/surface. Theres a man that coined the term the law of conservation of complexity: Complexity is neither created nor destroyed, we either move it above or below the surface, we let the automation or the users take care of it. I don’t know if I agree with that, but he has a point. There are ways to hide complexity and not expose the users to it, and automation and machine learning are a great way to simplify the user’s experience while still allowing the architecture to have some level of complexity. But all that being said, we still want to look for opportunities or instances where below the skin we’ve complexified things to the point where it becomes heavy and hard to debug/maintian. The back end matters too, its not just about the UX or UI.


Join our meetup group to hear about our other events!