Understand, don’t just follow
It still surprises me, and scares me, how many people in our industry that just follow ideas and practices just because “someone” says it is the way to go, and how those same people do not understand why they are actually doing it.
Let me give you an example.
When Kent Beck and his extreme programmers started out (with XP – extreme programming), they were talking about not writing comments in your code. And they explained what they meant: Comments are often an indication that your code isn’t readable on its own, the fix is often to write code that is easier to understand, not to add comments.
For me this is great advice. I try to keep my code clean and readable, and when I feel the urge to write comments, I first check if I can make the code more self explainable on its own. I personally write some comments, but never to explain code that looks like crap.
The problem with this advice is that it is actually bad advice if you do not understand why you should follow it. Those that do not understand why they should reduce their amount of comments, but still dig the idea, are probably writing as unreadable code as they always did, but now explaining the mess with even less comments. The result is probably all over worse code than if they didn’t follow the advice in the first place!
There are at least two lessons to be learned here.
First, if you do not understand why you are doing something, you are probably doing it wrong. It is time to start questioning what you are doing, always ask why.
Second. Say too many people misunderstand the purpose of something, thus applies it wrong, and thus is actually producing worse results than before. In our “no comment” example, people would, based on empirical evidence of the practitioners, say that the “no comment”-idea is a joke (since most of its followers are actually writing worse code). So by applying the idea wrong you are probably discrediting the whole idea.
I like to define agile in one sentence: “Ask Why”. “Why should we write this piece of documentation?” “Why should we follow this process?” “Why should we follow this practice?” If we better understand what we are doing, and can adjust our practices accordingly, I think we will get a long way. I think this is the core of agile.
- Tore Vestues


I would like to recommend you try reading one of the seminal works on organizational learning, “Situated Learning”, by Lave & Wenger. Although this is not a book dealing specifically with programming, it might offer a more fundamental appreciation of why people do not understand the same thing although they appear to have access to the same information. Why is your “truth” not someone else’s truth? While a discussion on what constitutes sound program development is a legitimate question in one context, the picture tends to blur as you cross the borders between communities of practice that abide by different quality criteria. The multidimensional implications of cross disciplinary development processes are still little understood.
May 18th, 2009 at 15:34 (690)