Pittsburgh Ruby Talk: Software process, the good parts
Who? Andrew Clay Shafer, @littleidea (puppet, conferences, involved/writing on devops)
When? 5-January-2012
What? Great, inspiring talk on software process, different types of agile and their core meanings (rather than the headlines people echo, often mindlessly) coming from someone who has obviously thought about these for quite a long time and internalized some deep lessons.
(these are my minimally translated notes from the meeting, they won't all necessarily make sense out of context)
Agile
- first impression: hated it
- scrums: felt like lots of STUFF, not much getting done
- beware the expert
- some people say 'agile', they mean 'scrum'
- Salt Lake Agile Roundtable: Alistair Cockburn (!!!) runs it, 2-5 on
the first thursday every month (during work, it's serious!)
- mix of companies (novell, motorola, startups) and people
- went there to get ammunition, but what he found was more interesting (smart people discussing ideas)
- image from Crystal Clean (context for everything) (size vs criticality)
Crystal
- frequent delivery
- reflective improvement
- close/osmotic communication (speed with which ideas can move thru organization)
- personal safety (willingness to put yourself out there)
- focus
- easy access to expert users (your customer!)
- automated tests, configuration management, frequent integration
Context matters
- criticality
- size
- scope
- schedule
- contractors (interfaces and coupling; who does the interfaces? -- how big is your tribe? ==> conway's law)
- distributed
MVP: Mimimally viable process
- XP: Jedi of agile (if only Kent Beck would come out of the swamp)
- Lean: Mary Poppendeck (first person to bring lean into software; mostly about building businesses and building pipelines of value)
- Kanban: (feel it's the most useful way to build software right
now)
- focus on quality
- reduce WIP
- deliver often
- balance demand against throughput
- prioritize
- attack sources of variability to improve predictability
- visualize the flow: if you see a bottleneck, you can stop the line and get the whole team involved
- Lean startup: read "Four Steps to the Epiphany" before "Lean Startup"
Reflect
- hardest thing to do: inspect and adapt
- cargo culting: all ceremony, no substance
- ARxTA (Brian Marick): We believe Agile software development is being dumbed down... (full quote)
- Working software is the primary measure of progress (like from the Agile Manifesto)
- OODA loop: Observe, Orient, Decide, Act; Building vs Planning: but why are we building it?
- David Hussman, Dude's Law: Value = Why / How
- @ salt lake thing: moratorium on talks on estimation, it's too hard
Vision
- hardest thing in software is capturing the vision
- Antoine de St Exupery quote ("...vast and endless sea")
- user story is a promise to have a conversation, not a spec!
- backlog is a ghetto... where stories go to die
- story mapping: write stories that capture the whole value (embrace the epics, we need to know this stuff!); what's the minimal span of those stories? this is the 'walking skeleton' => do enough to get the skeleton moving
Teams
- we design systems, why don't we design teams?
- different strokes (meh)
- CAP theorem: applies to people, too! -- if you require consistency, you give up availability: meeetings are global locks (is P related to co-location vs distributed?)
- Six laws of reliability (Joe Armstrong, Erlang): isolation, concurrency, failure detection, fault identification, live upgrade, stable storage => apply this to process (live upgrade => bringing on new people)
- FSOP cycle (flying by the seat of our pants):
smart people FSOP >
successful patterns emerge >
patterns recognized and adopted as process >
structures created to drive/moniotor process >
process becomes painful >
smart people reject the process >
(start from beginning)
Advocate
- really like kanban
- like XP tech practices
- focus on quality
- everything depends on context, but in context make policies explicit (this is fuzzy to me -- true that everything depends on context, but there's a tension with too much +/or the right kind of policy, e.g. "what's in your coding standard doc?")
- if something doesn't feel right, you're doing something wrong; might be that thing, might also be you...
- if you aren't getting results, change something
- if you're changing too much too often, you won't get good results
- measure (but don't get caught up in vanity)
- process is a competitive advantage, passion is a competitive advantage, but don't let process kill passion
- smart people solve problems
Q + A
Q: heard it said that scrum is kind of training wheels for
kanban/lean, true?
A: more reason for people to sell scrum; kanban is easier!
Comment: Agile manifesto says "people over process", but agile people are obsessed with process!
Physical precision
The new physicality brought an unexpected element into the act: precision. My routines wove the verbal with the physical and I found pleasure trying to bring them in line. Each spoken idea had to be physically expressed as well. My teenage attempt at a magician's grace was being transformed into an awkward comic grace. I felt as through every part of me was working. Some nights it seemed that it wasn't the line that got the laugh, but the tip of my finger. I tried to make voice and posture as crucial as jokes and gags....Finally, I understood the cummings quote I had puzzled over in college: "Like the burlesque comedian, I am abormally fond of that precision which creates movement." Precision was moving the plot forward, was filling every moment with content, was keeping the audience engaged.
Steve Martin, Born Standing Up
Consistent work
The consistent work enhanced my act. I learned a lesson: It was easy to be great. Every entertainer has a night when everything is clicking. These nights are accidental and statistical: Like lucky cards in poker, you can count on them occurring over time. What was hard was to be good, consistently good, night after night, no matter what the abominable circumstances.
Steve Martin, Born Standing Up
That reminds me...
...I need to watch Spinal Tap again. Who are you people who pretended to see it but didn't actually? The mind boggles. That film doesn't age for me as many comedies do (Strange Brew for instance -- still love it, not the same experience). Other Guest + Co. productions are similar in their longevity. May they continue.
Happy anniversary!
Eleven years ago, on a blustery, snowy Pittsburgh day, I married my favorite person. Lucky me, lucky us.
Impressions of Pittsburgh Geek Out Day
Pittsburgh Geek Out Day on Saturday morning was very stimulating. It's an open spaces conference, which essentially means the sessions, and content within a session, are determined on the fly by the participants. I think this was a little disconcerting at first for some people but wound up working well.
I'd guess about two dozen people attended, which IMO is pretty good for a first-time, Saturday-at-8:30-AM meeting. About 25% of the attendees were from Summa, though they didn't explicitly mention that. In fact, they took pains to separate their presence from the event, not wanting people to assume this was some sort of recruiting/advertising exercise. It certainly didn't feel that way to me -- even the 'thanks' for the free bagels/juice/coffee came at the very end.
The day started with an intro to the process, then people briefly announced their discussion ideas before sticking them up on a wall, proposing a time/room for it -- there were three timeslots and three rooms, so only nine discussions. (The room distinction was mostly irrelevant.)
I proposed three ideas with the intent that only one of them would probably go in because lots of other people would chime in. But the number of sessions wasn't as overwhelming as I thought, and it turned out all three were on the schedule. This was okay, but had the downside of missing other good discussions. That's a normal side-effect of getting a number of engaged and bright people together, but being a facilitator means you can't use the "law of two feet" to explore another one.
The law of two feet is a simple thing -- if you're not getting anything out of a discussion, nor are contributing to it, then you have not only the option, but the responsibility to move elsewhere. But its implications are much deeper. There's no second-guessing about whether a topic is interesting or useful; if not, people will change it or leave.
It's exhausting for me to determine whether people are into a topic, or whether I'm talking too much, or not enough -- my social antennae are stunted or something. So I found this a wonderful constraint. It also strikes me as very adult, as in you're treating your discussion colleagues as adults by allowing them to make their own decisions.
The topics I attended weren't earth shattering, but wandered into pretty meaty areas. The first was on managing distributed teams, ostensibly with agile but we wound up discussing communication and management problems in general, how different personalities affect what you need to do, and a topic ('Cognitive Systems Engineering') that I want to learn more about. There were only three people in this one, but I felt like we could have talked for another hour or two, easily. (More with beer.)
The second was on 'continuous deployment', a topic I'd proposed. We spent a good bit of time on a couple of concrete problems, which was excellent because it grounded the discussion. One of the conclusions I had reinforced was that, even if you cannot do continuous deployment, the act of trying to create the process (lots of automation and streamlining) has good results. Only four people in this one.
The last was on sharing technical and domain knowledge with your team, though it really focused on the former. About 12 people in this one, a lot of it around getting people up to speed (code reviews/desk checks seemed to be the most mentioned method).
Overall, the day was just great. It was exhilarating talking with people having the combination of: experience, useful reflection on that experience, lack of ego, and the desire to learn more. I look forward to more.
One of the things they don't tell you...
(At least for me.) When you become a parent, many stories you hear about kids just cut through all your cynicism callouses and hit your emotional core in nothing flat. This story from Anthony Griffith just had me crying in a public place.
I am not a praying person. But I do recognize my immense good fortune, and I'm thankful for it.
Furniture churn
Lots of furniture churn today.
Out:
- Dining room table and six chairs
- China closet
- Dining room light fixture (the first one I put up in the house, one of the few handy things I can do)
- Corner desk and chair (from the attic)
- Sofa table and side table (from the attic)
- Mica table lamp (from the attic)
In:
- Dining room table and four chairs (two left to assemble)
- Dining room light fixture (should be arriving Monday or Tuesday)
This is a pleasing imbalance.
More to come -- writing, not furniture. It's been missing for a while, in more ways than one.
Hiring two Java developers
We're hiring two Java developers to my team in Pittsburgh!
Some non-HR skinny about us:
- We are a small and empowered team. There is no committee that decides whether you can start using Google Guava to make things better.
- We get to do meaningful things -- this is not "shovel CRUD onto the web" type of work. We change the lives of people living and working in skilled nursing facilities.
- Java experience is a must. Yes, you can learn a language really quickly, but that's the easy part. Absorbing the libraries and the ecosystem takes a lot of time.
- We have a lot of work to do, but we don't burn ourselves out doing it.
You will probably[1] have a leg-up if you've got any of the following:
- some UI design and implementation chops,
- deep understanding of JavaScript the language,
- use of Spring in anger (double word score for 3.0),
- knowledge of healthcare data interchange (HL7),
- working knowledge of unix systems.
Let me know if you're interested, or if I can fill you in on more details.
[1] Speaking for myself and not for the rest of the potential interviewing team...
Small ttree config change fixes site
When I got my new laptop I reinstalled a bunch of perl modules, tending to do it on an as-needed basis vs the autobundle reload. ("What bothers you about that, the ease, the convenience...?" Anyway.) And it loaded a new version of the Template Toolkit. Apparently between the version on my old laptop and this one a number of changes had been made to ttree, which generates this site. And when I ran my publishing script it dutifully generated the Atom feed, put the new post on the front page, and uploaded it to the site.
But I got an email from someone that the actual permalink resulted in a 404. A little closer looking found that ttree wasn't generating my files! I vaguely remembered having to patch ttree and looked around for a post on that, no luck. Turning on verbose mode ('verbose = 2') in ttree.cfg showed this:
cwinters@abita ... $ ttree -f ./ttree.cfg
ttree 2.9 (Template Toolkit version 2.22)
Source: content
Destination: site
Include Path: [ templates ]
Ignore: [ ]
Copy: [ \.(css|js|html|xml|atom)$, ^robots\.txt$ ]
Accept: [ \.txt$ ]
Suffix: [ txt => html ]
Summary:
0 files processed
0 files copied
0 directories created
2 files skipped (not modified)
21 files skipped (ignored)
Hmm... that number of files skipped is really low. A little more checking revealed that I needed to explicitly specify recursive behavior, with 'recurse = 1'. Everything is now as it should be, and now that I don't need to patch ttree no more surprises should pop-up.