InfoQ Homepage Presentations The Limited Red Society
The Limited Red Society
58:07
Summary
Joshua Kerievsky discusses the need to reduce “red” periods of time while developing software. One is in the red when he spends too much time designing, or having compilation errors or the tests do not pass. Kerievsky demonstrates a method (Parallel Change) of reducing the red while refactoring code, and discusses another approach called Narrowed Change, and answers refactoring related questions.
Bio
Joshua Kerievsky has been programming professionally since 1987, and is the founder of Industrial Logic (http://industriallogic.com), a company specializing in Extreme Programming (XP). Joshua has been an active member of the XP and patterns communities, he wrote a book called Refactoring To Patterns and he created Industrial Extreme Programming.
About the conference
Lean Software and Systems Conference 2010 — the place to learn about Lean, Pull Systems and Kanban. Understand how established industrial engineering theory can apply to software development process. The conference will assist organizations that depend on software – from start-ups to those that build complex, software intensive products, systems & services – with the application of Lean Thinking throughout the enterprise.
Jun 03, 2010
Community comments
What about ATDD?
by Eetu Huisman,
Re: What about ATDD?
by Joshua Kerievsky,
Responsive Design
by Daniel Ribeiro,
Re: Responsive Design
by Joshua Kerievsky,
What about ATDD?
by Eetu Huisman,
Your message is awaiting moderation. Thank you for participating in the discussion.
I found the presentation extremely (pun intended) interesting. I know I have sometimes used the parallel change "pattern" myself without even realizing how useful it could be in other situations.
What I was thinking about (and I don't think any of the questions presented by the audience touched this) was how does this apply to acceptance test driven development. Acceptance tests are by definition written beforehand, because their meaning is to a) make the story more understandable for the team and to b) make sure that the requirements of the story are really met. They are typically "red" until the functionalities they require are implemented, thus the story is more or less "done".
Maybe failing new (story) acceptance tests shouldn't even show up as red, but as yellow or something. On the other hand, they do tell that there is work in progress, which should be limited. If we create just one test at a time, we miss the big picture completely, which doesn't seem like a good idea, either.
Is there something crucial I'm missing here?
Responsive Design
by Daniel Ribeiro,
Your message is awaiting moderation. Thank you for participating in the discussion.
Paralell Change is one of the design principles in Kent Beck's responsive design theme. It was also presented on a qcon last year.
Re: Responsive Design
by Joshua Kerievsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Daniel,
I've been using the term Parallel Change for at least 4 years now, talking about it in my Refactoring Strategies & Tactics tutorials (formerly called Patterns of Refactoring) and showing videos of these strategies in my Refactoring eLearning album (bit.ly/9T5S9I). So it may just be that Kent selected a similar name to mine. I have to read his stuff and see how close it relates to the technique I'm referring to.
Here are a few more Refactoring strategies I've been writing about over the years:
* Piecemeal Change
* Gradual Change
* Narrowed Change
* Sequence Change
* Evolved Target
* Unified Methods
* Graceful Retreat
I will blog about these one day.
Re: What about ATDD?
by Joshua Kerievsky,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't think you're missing anything. If you do ATDD (or as we call it, Storytest-Driven Development), you will have work-in-progress and it will be good to work in such a way that you aren't "in the red" for very long periods of time, even though they will be longer than if you were just doing TDD.
BTW, there was a time when we did ATDD all of the time and now we're much more selective about doing it.