Demonstration: Applying the Parallel Change technique to change code in small, safe steps

The Parallel Change technique is intended to make it possible to change code in a small, save steps by first adding the new way of doing things (without breaking the old one; “expand”), then switching over to the new way (“migrate”), and finally removing the old way (“contract”, i.e. make smaller). Here is an exampleContinue reading “Demonstration: Applying the Parallel Change technique to change code in small, safe steps”

Refactoring & Type Errors in Clojure: Experience and Prevention

While refactoring a relatively simple Clojure code to use a map instead of a vector, I have wasted perhaps a few hours due to essentially type errors. I want to share the experience and my thoughts about possible solutions since I encounter this problem quite often. I should mention that it is quite likely thatContinue reading “Refactoring & Type Errors in Clojure: Experience and Prevention”

The Sprinting Centipede Strategy: How to Improve Software Without Breaking It

Re-published from Our code has been broken for weeks. Compiler errors, failing tests, incorrect behavior plagued our team. Why? Because we have been struck by a Blind Frog Leap. By doing multiple concurrent changes to a key component in the hope of improving it, we have leaped far away from its ugly but stableContinue reading “The Sprinting Centipede Strategy: How to Improve Software Without Breaking It”

Most interesting links of January ’12

Recommended Readings Jeff Sutherland: Powerful Strategy for Defect Prevention: Improve the Quality of Your Product – “A classic paper from IBM shows how they systematically reduced defects by analyzing root cause. The cost of implementing this practice is less than the cost of fixing defects that you will have if you do not implement itContinue reading “Most interesting links of January ’12”

Refactoring Spikes as a Learning Tool and How a Scheduled Git Reset Can Help

To learn how complex your code base really is and how much effort a particular refactoring might require compared to the initial expectations, follow these steps: Schedule git reset –hard; git clean -fd to run in 1 hour (e.g. via cron) Do the refactoring “WT*?! All my changes disappeared?!” – this experience indicates the endContinue reading “Refactoring Spikes as a Learning Tool and How a Scheduled Git Reset Can Help”

Most interesting links of September

Recommended Readings J. Yip: It’s Not Just Standing Up: Patterns for Daily Standup Meetings – it isn’t easy to make stand-up meetings short, focused, energizing, and centered around continuous improvements and team spirit. This description of an example good standup, the meeting’s goals, and especially the “patterns” and “bad smells” can be pretty useful to get andContinue reading “Most interesting links of September”

Most interesting links of August

Recommended Readings Martin Fowler on the problem of software patents – “… while patents (even software patents) are a good idea in principle, in practice they have turned into an unmitigated disaster and would be better scrapped.” Discovering Hidden Design, Michael Feathers – When refactoring complex code towards a better design with clearer separation ofContinue reading “Most interesting links of August”

Most interesting links of May

Recommanded Readings Acceptance testing / Specification by example: Gojko Adzic: Anatomy of a good acceptance test – an example of refactoring a bad acceptance test into a good one – good for learning about pitfalls and how a good one should look like Gojko: Top 10 reasons why teams fail with Acceptance Testing – acceptance testing isContinue reading “Most interesting links of May”

Refactoring the “Legacy” with the Mikado Method as a Coding Dojo

I’m preparing a coding dojo for my colleges at Iterate where we will try to collectively refactor the “legacy” Hudson/Jenkins, especially, to something more testable, using the Mikado Method. I’ve got the idea after reading Gojko Adzic’s blog on how terrible the code is and after discovering the Mikado Method by a chance. SinceContinue reading “Refactoring the “Legacy” with the Mikado Method as a Coding Dojo”

Book review: Refactoring by Martin Fowler

I had high expectations for Martin Fowler’s Refactoring (1999/2002) but it turned out that both me and the book are too old. It had some interesting parts, but the main one – the refactoring catalog itself – had little new for me because I already know most of the refactorings and the description of stepsContinue reading “Book review: Refactoring by Martin Fowler”