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.
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.
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.
What about ATDD?
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?
Re: Responsive Design
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?
BTW, there was a time when we did ATDD all of the time and now we're much more selective about doing it.