Glen Peterson uses the Expression Problem to compare refactoring in Java, Scala and Clojure, showing how traits minimize changes in Scala when an interface changes and how Clojure avoids some of the issues.
Ann Robson discusses how to develop standards, approach refactoring in a safe and practical way, and track the evolution of a code with tools and metrics.
Felienne Hermans introduces BumbleBee, a refactoring and metaprogramming spreadsheets tool based on a DSL that can perform transformations against spreadsheet formulas.
Simon Thompson shows the particularities of functional programming refactoring through examples in Haskell and Erlang, and discusses what lays ahead for FP refactoring in the next 10 years.
Greg Young discusses eight lines of very common code finding in them massive numbers of dependencies and difficulties, looking for ways to get rid of them.
Sandro Mancuso runs a hands-on demo adding tests to a Java legacy code then refactoring it.
Simon Thompson introduces Wrangler, a refactoring tool written in Erlang for Erlang code and embeddable in common IDEs, such as Emacs and Eclipse.
Nat Pryce considers that we cannot write the perfect code because it is never fully prepared for the coming change, so he suggests embracing impermanence & continual imperfection.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Jason Gorman presents how developers can learn TDD to the point of transforming the knowledge acquired into habits by exercising a number of practices over a period of 4-6 months followed by evaluation done by fellow co-workers.
Ralph Johnson discusses principles, practices and tools relating to software development starting not from scratch but from already existing code which needs refactoring, maintenance, and sometimes architectural change.
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.