at the Limited Red Society session (Joshua Kerievsky)
A compilation or refactoring "rash": when your IDE is showing a bunch of red in the gutter.
Joshua's live-coding to demonstrate how to stay "out of the red".
He's introducing type safety via enums (Java).
"I can't fix that [urgent] bug, I'm in the middle of refactoring"!
Uh oh, Joshua is still "in the red", and the users are complaining about an urgent bug that needs to be fixed ASAP.
Oops. Because he took to long to get to Green (tests passing), the users (Doctors) couldn't use the system and people died.
A rash is when you have a bunch of compile errors and have to get rid of them one-by-one. Joshua spent 64% of his coding time in that state.
When the code is in a red state, you are constrained because you can't fix urgent issues. When the car is "up on blocks", then you can't go anywhere.
Joshua's company has been doing 1-2 deployments per week, but should be at continuous delivery this summer.
Became a priority for them to be able to redeploy when users are still logged in (changing the tire while the car is moving).
Not just defect fixing, but a "continuous flow of value".
The longer that you're "in the red", the harder it is to do a retreat (though if you just rollback, you've perhaps wasted a lot of time -- that "waste" might not be bad).
Parallel Change: break the refactoring into much smaller pieces: build parallel in the code and then switchover only when done, e.g., make overloaded methods that support the new type, but still works with old code. And tests still pass.
Doing Parallel Change seems like a good way to stay out of "the red", but I think it has a higher cost. I think this is suitable for systems that can be quickly deployed, but for Enterprise systems, not so much?
"For something as humble as the rename" refactoring, there are deeper/more advanced things that you can do, such as change getter/setters for you even if you just renamed an internal private variable.
"For constants that you no longer need, but are referenced in tests, you can just inline them."
Lesson: find a way to do big changes in small ways. Experts _could_ do "big leaps", but should really try to avoid them. #lssc10
Are features that are deployed, but turned off, still considered WIP? #lssc10
RT @testobsessed: Point of Agile-friendly acceptance test tools is to support collab, not to enable auto by non-techies.Crucial distinction.
Help programmers improve by giving them feedback on their time "in red". #lssc10
There's always a way to slice things into smaller pieces, which makes you more nimble. Finding that way is worth the time. #lssc10
At the "Measure for Measure" - Lean Principles for Effective Metrics and Motivation #lssc10
I'm really interested to see how this talk relates to the research and reading I've been doing on motivation, metrics, productivity, etc., from Deci, Pink, Austin, etc.
Richard Hensley is quoting "You can't control what you can't measure" - Tom DeMarco.
Results of a survey sent out to Agile Denver: 10% response rate (I argue that this is "statistically significant", though). Test (code) coverage and Number of Features/Stories delivered and Release Burndown are all quite high.
Relating the oft-told story of Tom Sawyer getting his friends to whitewash the fence -- with respect to motivation (Purposeful Work).
Is there an acceptable level of extrinsic rewards for motivating 7-year olds? Perhaps. But certainly not for adults at work. #lssc10
Sigh. The downside of multiple tracks at a conference: want to be in 3 places at once. #lssc10
Glad to see Richard Hensley is using research on motivation, though wish he started talking about how that relates to metrics 20 minutes ago.
Richard now discusses Robert D. Austin's book (http://amzn.to/dtg2yr): measuring for performance causes _drop_ in performance. #lssc10
btw, saw the awesome CardWall (http:///www.cardwalls.com) from Pillar @agilesoftware #lssc10
Would have preferred more experience report/case study of actual metrics used in a company that follow motivational principles. #lssc10
I feel that not mentioning specific metrics with appropriate context is the easy way out. Or at least providing negative examples. #lssc10
(Kanban) Need to inflict the right amount of pain - requires understanding of WIP limits and Little's law. #lssc10
Looks like I picked the wrong session this time...ah well.
Oh, and I thought Richard Hensley's talk had a _lot_ of really good information. Alas, I already knew much of it from my recent research into motivation.
Apparently Kanban was independently invented by Arlo as "Naked Planning". #lssc10
Work cell in manuf.: worker moves through multiple steps of assembly, reducing hand-offs and inventory. #lssc10
Highly specialized craftsman didn't like having it - required different skills for each part of work cell. Sound familiar? #lssc10
Really big holding costs in software: can't deploy just pieces of features, you need the whole thing to be deployable. #lssc10
