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”

JDBC: What resources you have to close and when?

I was never sure what resources in JDBC must be explicitely closed and wasn’t able to find it anywhere explained. Finally my good colleague, Magne Mære, has explained it to me: In JDBC there are several kinds of resources that ideally should be closed after use.  Even though every Statement and PreparedStatement is specified toContinue reading “JDBC: What resources you have to close and when?”

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

Re-published from blog.iterate.no. 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”

Programming Like Kent Beck

Republished from blog.iterate.no with the permission of my co-authors Stig Bergestad and Krzysztof Grodzicki. Three of us, namely Stig, Krzysztof, and Jakub, have had the pleasure of spending a week with Kent Beck during Iterate Code Camp 2012, working together on a project and learning programming best practices. We would like to share the valuableContinue reading “Programming Like Kent Beck”

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”

Real-world data prove that Agile, BDD & co. work – lecture by G. Adzic

I’ve attended a very inspirational lecture by Gojko Adzic, organized by the Oslo XP Meetup. Many people including some respectable persons claim that Lean, Agile, and high-level testing based on specifications (whether you call it Agile acceptance testing, Acceptance-test driven development, Example-driven development, Story-testing, Behavior-driven development, or otherwise – let’s call them all Specification byContinue reading “Real-world data prove that Agile, BDD & co. work – lecture by G. Adzic”

Most interesting links of December

In the last month of 2010 I’ve stumbled upon surprisingly few intersting articles, partly due to having a lot to do in my job. Reusable Code Is Bad (for advanced developers only!) – we know duplication is bad but “premature enabling for reuse” is equally bad – or ewen worse – because it introduces moreContinue reading “Most interesting links of December”