the pivotal engineering dojo: earning your black belt in cloud foundry engineering (cloud foundry...
DESCRIPTION
Business Track presented by Michael Maximilien, Chief Architect PaaS Innovation at IBM.TRANSCRIPT
CF dojo experience earning your black belt in CF engineering
dr.max @maximilien julz friedmanibm cloud labs v0.5.0
June 11, 2014
photo credit: http://urbosquid.com
2
photo credit: The Matrix, Warner Bros.
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
photo credit: The Matrix, Warner Bros.
It Works!
photo credit: The Matrix, Warner Bros.
In theory, there is no difference between theory and practice, however, in practice there is.
Big company agile vs. Pivotal agile
some differences
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
• 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
.. probably not for everyone
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
• 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
photo credit: The Matrix, Warner Bros.
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
standups
18
pairing
19
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
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
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
photo credit: The Matrix, Warner Bros.
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
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
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
photo credit: The Matrix, Warner Bros.
Thank you Q & As
28
Backup
photo credit: The Matrix, Warner Bros.