It Is OK to Require Your Team-mates to Have Particular Domain/Technical Knowledge

Should we write stupid code that is easy to understand for newcomers? It seems as a good thing to do. But it is the wrong thing to optimise for because it is a rare case. Most of the time you will be working with people experienced in the code base. And if there is a

Don’t add unnecessary checks to your code, pretty please!

Defensive programming suggests that we should add various checks to our code to ensure the presence and proper shape and type of data. But there is one important rule – only add a check if you know that thing can really happen. Don’t add random checks just to be sure – because you are misleading

The Are No Silver Bullets: Which Error Handling Style to Pick For a Given Configuration of Constraints?

Kent Beck in his Patterns Enhance Craft Step 3: A Few Good Solutions highlights an important fact about software development: We encounter repeating configurations of forces/constraints that have only a handful of “solution families” and the optimal solution(s) depend on the relative weights of these constraints. For example when deciding what error handling style we

Challenging Myself With Coplien’s Why Most Unit Testing is Waste

James O. Coplien has written in 2014 the thought-provoking essay Why Most Unit Testing is Waste and further elaborates the topic in his Segue. I love testing but I also value challenging my views to expand my understanding so it was a valuable read. When encountering something so controversial, it’s crucial to set aside one’s emotions

Focus & Do the Simplest Thing Possible

Are you tired of days spent in front of the screen, with no results to show? Have you once again engaged in yak shaving? Today, after having failed previously, I have finally managed to solve a problem while avoiding this trap by following rigorously two guidelines preached by grandmaster programmers. Be warned: Following this approach, you will get a working solution – but you won’t like it. It will be ugly, stained by compromises, far from the elegant solution you wish for. But if your resources are limited and you want to avoid death by too many yaks, this is your only option. But first, what are these guidelines?

One: Maintain a laser-sharp focus. A great programmer is constantly aware of what she is trying to achieve and never strays far from it. If the path leads away, she backs up. If something else pops up, she writes it down for later and gets back to the job. This is essentially about deciding what not to do. (Many thanks to Kent Beck for sharing his focus secret!)

Tiny, Tiny Steps – Experience Report Developing A Feature In Minimal Value-Adding Increments

A post for those who want to see what an iterative, MVP-driven development of a feature looks like. @lukew: Start with the simplest version you can. It’s much easier to add complexity than to remove it. Once upon time, there was a webshop portal with hundreds of partner webshops displayed on the front page. Potential

Frustration-Driven Development – Towards DevOps, Lean, Clojure

A post about development practices, speed, and frustration. My wife has mentioned that she likes my passion for doing things right in software development. That made me thinking, why do I actually care so much and do not just enjoy the coding itself? It boils down to that I am not happy until my code

Seek Understanding

The most important lesson I have learned in 2013 is that I won’t change anything by writing critical blog posts and talking to like-minded people. Fostering the “we vs. them,” we who are right vs. them idiots sentiment is ineffective, even destructive. To be able to achieve anything, I have to talk to the people

The Risks Of Big-Bang Deployments And Techniques For Step-wise Deployment

If you ever need to persuade management why it might be better to deploy a larger change in multiple stages and push it to customers gradually, read on. A deployment of many changes is risky. We want therefore to deploy them in a way which minimizes the risk of harm to our customers and our companies. The

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