by Gene Kim on
@DevOpsDaysTokyo: RT @yuhattor: #DevOpsDaysTokyo
9 practices by @ToBeAgile
1:Say What, Why, and for Whom Before How
2:Build in Small Batches
5:Create CLEAN Code
6:Write the Test First
7:Specify Behaviors with Tests
8:Implement the Design Last
9:Refactor Legacy Code
@tobeagile: "Many developers are running their tests 3 times per minutes" (every time they hit Save)
@tobeagile: "Every field has the notion of productization: it's done, done, done; integrated into build, cleaned up and made supportable
@tobeagile: "the first step in every project should be to set up CI; it makes any programmer better"
@tobeagile: "People say devs are bad communicators; I disagree; we may not always like smalltalk, but we love high-bandwidth communications and we're good at it; it's part of our job
@tobeagile: "Pair programming: managers don't like it because they think they lose 50% of their 'resources'; you're bringing to bear two minds to solve a problem; would they object to having 2 people move very heavy furniture?" (Ha!)
@tobeagile: "you can only do pair programming for 3-4 hours in a day, because it's so exhausting, but satisfying; I love 'buddy programming': one hour of review/peer/working together at end of day
@tobeagile: "Spike: few people research unknowns in a fixed time box; Swarm: all work to solve a problem; Mob: when whole team works together on the same story; watch 5m video at http://MobProgramming.org for a chronicle of an 8 hour mob
@tobeagile: "In a spike: we can identify and encapsulate what we don't know, so we can more easily deal with it later
@tobeagile: "My mentor, Scott Bain: always strive to be mentoring someone, and be mentored by someone
@tobeagile: "We can infer good dev principles and practices thru 5 key code CLEAN qualities: cohesive, loosely coupled, encapsulated, assertive, nonredundant
@tobeagile: "Cohesive: it's about one thing; single minded about one thing; no God objects; compose complex classes from simple classes
@tobeagile: "Loosely coupled: don't call code directly, which makes it testable and extensible
@tobeagile: "Assertive: has everything it needs to do its ob; it manages its own stage;
@tobeagile: "Encapsulated: inside and outside; we hide the implementation details behind an interface; separate the How with the What
@tobeagile: "Non-Redundant: doesn't repeat itself; it's okay for learning, but it always creates a maintenance issue
@tobeagile: "Practice 6: write the test first
@tobeagile: "To be fair, people in the 'TDD is dead' movement are facing real problems; they are often writing too many tests and implementation-dependent tests that actually 'damage' software, impeding refactoring; tests must enable refactoring, not impede it"
@tobeagile: "Refactoring lets developers have another chance to clean up their designs and make the code easier to work with in the future: clean the kitchen before preparing for the dinner party
@tobeagile: "Refactor legacy code: change structure of our code w/o changing its external behavior; it drops the costs of 4 things: understanding the code later, adding unit tests, accommodating new features, and do further refactoring
@tobeagile: "The cost of technical debt is paid whenever someone has to go into the code and understand it and modify it"; "refactoring is expensive, so if it's ain't broke, don't fix it; use the simple refactoring to introduce seams in the code so you can add tests to support more complicated refactoring
@tobeagile: "Refactoring to the Open-Closed; Software should be open to extension, and closed to modification;
It's cold and rainy today, but I am here at #devopsdaystokyo expanding my mind... Gene Kim is here, enjoying rock star status. It's infectious... I got a bit giddy when I heard he has a new book coming in November!
while they get slides ready, @kohsukekawa is telling the origin story of Jenkins to the appreciative crowd here at #DevOpsDaysTokyo. Awesome!
@kohsukekawa: 200K+ installations, helping teams everywhere;
@kohsukekawa: piles of e-waste may contain more gold than a gold mine
@kohsukekawa: "100s of engineers; 10s of projects; 1 shared Jenkins infrastructure: $100Ks of AWS cost; CFO asks why do we spend so much on cloud? Build times for small/med/larger: 15m/10m/8m; Costs: $1k/$2K/$3K. A build fails, who should be notified first?
@kohsukekawa: "What did they do? Used regular expression pattern matching, Bayesian filter.
@kohsukekawa: "80 devs; Dev/QA/Ops; 10s of microservices; frequent promotion of apps; when is my change in UAT? QA failed, what has changed? Who should look?"
@kohsukekawa: "Problem: I want to improve our software delivery process, but it doesn't get prioritized"; Data and story helps your boss see the problems that you see; data helps you apply effort to the right place
@kohsukekawa: "Massive, modularized codebse w/web of dependencies; big, time consuming tests around them; Question: I want to cut cost and time of the software delivery process; several thousands of modules; calculate which tests should be run
@kohsukekawa: "ML model predicts which useful subset to run; of 10^5 changes/month, 1% is used to train the model; impact: only 1/3 of tests are selected; misses just 0.1% of broken changes; AWS costs cut in half
@kohsukekawa: "Sitution: you are SRE in a BigCo; 100s of apps; about 1 deploy/app/day; can we flag risky changes beforehand?
learning: most outages are estimated as low/risk by developers; most outages had short time span till approved; long maintained code is more risky!
require somebody to be on call; restrict window of deployment
donkeys: different teams are doing different things; Devops being glorified IT or internal PS; app teams don't see value
unicorns: everyone does things one way; Devops team is autonomous; app teams feel like bullshit is taken care of; positive feedback loop makes the one way is the best way
@kohsukekawa: "Advice: latch on to cloud migration or microservice transition