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

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

2. 2
photo credit: The Matrix, Warner Bros.

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
photo credit: The Matrix, Warner Bros.

7. It Works!

8. photo credit: The Matrix, Warner Bros.

9. In theory, there is no difference between theory and
practice, however, in practice there is.

10. Big company agile vs. Pivotal agile
some differences

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

13. .. probably not for everyone

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

16. 16
photo credit: The Matrix, Warner Bros.

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

18. standups
18

19. pairing
19

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

23. photo credit: The Matrix, Warner Bros.

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

27. 27
photo credit: The Matrix, Warner Bros.

28. Thank you
Q & As
28

29. Backup

30. photo credit: The Matrix, Warner Bros.