The Pivotal Engineering Dojo: Earning Your Black Belt in Cloud Foundry Engineering (Cloud Foundry Summit 2014)


Published on

Business Track presented by Michael Maximilien, Chief Architect PaaS Innovation at IBM.

Published in: Technology, Business

The Pivotal Engineering Dojo: Earning Your Black Belt in Cloud Foundry Engineering (Cloud Foundry Summit 2014)

  1. 1. CF dojo experience earning your black belt in CF engineering dr.max @maximilien julz friedman ibm cloud labs v0.5.0 June 11, 2014 photo credit:
  2. 2. 2 photo credit: The Matrix, Warner Bros.
  3. 3. overview of this talk • how do I contribute to Cloud Foundry? ‣ yourself ‣ your company • why the dojo program? • is agile the same everywhere? • our experiences? 3
  4. 4. 4 photo credit: The Matrix, Warner Bros.
  5. 5. It Works!
  6. 6. photo credit: The Matrix, Warner Bros.
  7. 7. In theory, there is no difference between theory and practice, however, in practice there is.
  8. 8. Big company agile vs. Pivotal agile some differences
  9. 9. 11 • Single Coder • Sometimes a long time to come up to speed • Knowledge sharing by training sessions, some on-the-job training, documentation.. • Big difference in productivity between junior and senior programmers • Rely on code review, QA etc. @Big Company Single Coder
  10. 10. 12 • Mentally Taxing! • Very impressive team, quick working, have to be on your game to keep up • Reliance on high test coverage, code quality • Pairing is synchronous code review @Pivotal Pair programming
  11. 11. .. probably not for everyone
  12. 12. 14 • Quite agile, but adapted to the realities of the business (Distributed Programmers, Project Management, Detailed Feature Tracking..) • Sometimes uses Agile terms without actually being all that agile. • Some test-first development. But not nearly pervasive enough. credit: hardening-sprints-sorry-youre-not-agile.html @Big Company “agile” methodology
  13. 13. 15 • HEAVY reliance on test-first development, refactoring & communication • Huge opportunity to learn • e.g. Limited documentation, lightweight stories, minimal up-front architecture and design, aggressive refactoring + wicked fast feedback cycle. • Very effective BUT reliance on being in the room. • How to make it scale for a distributed project? (will come back to this) @Pivotal XP-style methodology
  14. 14. 16 photo credit: The Matrix, Warner Bros.
  15. 15. our dojo experiences • spent 7-8 weeks at Pivotal SF working with CF team • tried to work with as many teams as possible • primary goals were to: 1. learn CF codebase, lean how to debug, learn how to contribute 2. meet as many members of CF team as possible, build relationships 3. gain credibility for myself and IBM • overall experience positive - achieved most goals 17
  16. 16. standups 18
  17. 17. pairing 19
  18. 18. runtime team • maybe the most important CF teams (Diego + regular runtime) • runtime integrates all pieces. Runs and manages: Tabasco, A1, and Production Pivotal CF environments • typically seen as chaotic - especially while I was there (syslog issue) • always under lots of pressure, however, can be rewarding • not the ideal place to learn CF tools or CLI or CF itself, but great to learn internals of cloud-controller and DEA components 20
  19. 19. bosh team • under less pressure than runtime but nonetheless critical • vision for BOSH evolving to be a tool that can be used outside of CF • some “star” Pivotal engineers are on BOSH • has its own “language” (release, jobs, packages, spec, etc) • not the place to learn how to use BOSH, however, great to learn internals and its goals and directions • BOSH is great once you understand, learn its language, and learn its key goals 21
  20. 20. miscellaneous • got a chance to pair and meet docs team • got to meet, but not paired with, services team • got to meet and indirectly-pair with other team Pivotal product team members (especially Tempest, PHD, CLI) • good recap with Rob Mee and directors • got to provide feedback to Pivotal culture (good and bad) 22
  21. 21. photo credit: The Matrix, Warner Bros.
  22. 22. thoughts - positive • Pivotal has welcoming and “be nice” culture, easy to fit, but must contribute • striking mismatch between Pivotal culture and IBM’s (emails and meetings) • decisions are super fast since directors, PMs, and engineers are in close proximity • Pivotal is one of few companies doing XP with high-level of "discipline" and in particular Pair Programming and TDD • entire floor of two-floor Pivotal Labs in SF dedicated to CF (rotations all the time) • significant IBM contributions to CF will require embedding into that culture • no “schedules”, no dates, works get done when done... Pivotal tracker (similar to online RTC) is used to track work... GitHub for all code 24
  23. 23. thoughts - not so positive • lack of slack => engineers have hard time innovating (“story blinders”) • decisions while fast are not necessarily data-driven • pairing helps with feedback and checks, but => less external documentation • “fanatic” move to Go-lang seems to be generally welcomed but I think Go while good for some system-level things is not necessarily a panacea; Ruby will soon be missed :) • “Big ball of mud” happens for all software (Go, Ruby, etc). Second implementation helps with learning and getting better • TDD gets abused, sometimes - especially with overuse of mocks 25
  24. 24. thoughts (cont.) • highly recommended to all engineers wanting to contribute to CF • read and practice TDD and pairing and basic data structures • be ready to embed yourself into culture, be open, be nice • very few places do full agile, like Pivotal, so this by itself is a great learning experience • continue adding to you and company’s credibility • helps put a human face to the Github IDs or vcap-dev names 26
  25. 25. 27 photo credit: The Matrix, Warner Bros.
  26. 26. Thank you Q & As 28
  27. 27. Backup
  28. 28. photo credit: The Matrix, Warner Bros.