A Secret Weapon Against Technical Debt

(Cross-posted from blog.iterate.no.) Technical debt is not the only monster we have to fight – it has a hidden evil twin,  as pointed out by Niklas Björnerstedt: Competence Debt. The rope of ignorance that binds our hands and suffocates us by fear so that we don’t dare to change the system. Technical debt makes change difficultContinue reading “A Secret Weapon Against Technical Debt”

Bad Code: Are We Thinking Too Little?

Do we not think enough when coding? Do we jump to the first solution without really considering the problem, without trying to analyze and decompose it and understand the components and orthogonal forces invovled? Is that the cause of bad code (together with time press) and the reason why we typically see a “patchvolution” ratherContinue reading “Bad Code: Are We Thinking Too Little?”

Most interesting links of November ’13

Recommended Readings Some interesting topics this time despite me spending lot of time on the Principles of Reactive Programming course: Java x Node.js, REST x other future-proof architectures, scary legacy code. Of course, also plenty of Clojure. People, organizations, teams, development: Chris Argyris (1923-2013): An Appreciation – Thinkers 50 – recently departed Ch. Argyris isContinue reading “Most interesting links of November ’13”

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”

Help, My Code Isn’t Testable! Do I Need to Fix the Design?

Our code is often untestable because there is no easy way to “sense1” the results in a good way and because the code depends on external data/functionality without making it possible to replace or modify these during a test (it’s missing a seam2, i.e. a place where the behavior of the code can be changedContinue reading “Help, My Code Isn’t Testable! Do I Need to Fix the Design?”

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 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”

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”