Most interesting links of October ’12

Recommended Readings David Veksler: Some lesser-known truths about programming – things newcomers into the field of IT don’t know and don’t expect, true and an interesting read. Not backed by good data but anyway. F.ex.: “[..] a programmer spends about 10-20% of his time writing code [..] much of the other 90% thinking, researching, andContinue reading “Most interesting links of October ’12”

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”

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 July

Recommanded Readings Martin Fowler, M. Mason: Why not to use feature branches and prefer feature toggles instead, when branches can actually be used (video, 12min) – feature branches are pretty common yet they are a hindrance for a good and stable development pace due to “merging hells”. With trusted developers, feature toggles are a muchContinue reading “Most interesting links of July”

What I’ve Learned from (Nearly) Failing to Refactor Hudson

We’ve tried to refactor Hudson.java but without success; only later have I been able to refactor it successfully, thanks to the experience from the first attempt and more time. In any case it was a great learning opportunity. Lessons Learned The two most important things we’ve learned are: Never underestimate legacy code. It’s for moreContinue reading “What I’ve Learned from (Nearly) Failing to Refactor Hudson”

What Do I Mean by a Legacy Code?

I’m using the term “legacy code” quite a lot, what do I mean by it? I like most the R. C. Martin’s description in his foreword to the Michael Feathers’ book Working Effectively with Legacy Code: It conjures images of slogging through a murky swamp of tangled undergrowth with leaches beneath and stinging flies above. ItContinue reading “What Do I Mean by a Legacy Code?”

Refactoring the “Legacy” Hudson.java 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 Hudson.java, 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” Hudson.java with the Mikado Method as a Coding Dojo”

Code quality matters to the customers. A lot.

Some people argue that the main taks of a developer is to deliever working, value-bringing software to the customer and idealistic concepts such as code quality should not hinder that primary task. They acknowledge that it is good to strive for good code quality but say that sometimes code quality must give way to theContinue reading “Code quality matters to the customers. A lot.”

Clean Code: Four Simple Design Rules – Obligatory Read

I consider the Clean Code book to be obligatory for every programmer. And if you currently haven’t the time to read it all at once then you should read – and take deep into your heart – at least the 12th chapter Emergence by Jeff Langr, which introduces Kent Beck’s Four Simple Design Rules andContinue reading “Clean Code: Four Simple Design Rules – Obligatory Read”