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."
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).
Glad to see Richard Hensley is using research on motivation, though wish he started talking about how that relates to metrics 20 minutes ago.
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.