The Pivotal Engineering Dojo: Earning Your Black Belt in Cloud Foundry Engineering (Cloud Foundry Summit 2014)
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: http://urbosquid.com
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
11. 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
12. 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
14. 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: http://kasperowski.com/2010/09/
hardening-sprints-sorry-youre-not-agile.html
@Big Company
“agile” methodology
15. 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
17. 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
20. 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
21. 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
22. 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
24. 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
25. 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
26. 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