In the last days I have been thinking a lot about my ideas and thoughts on methodologies. This was triggered by the discussions around ISO 29119. When thinking about it, I found myself back at my starting position rather quickly: there are a lot of methods to learn, most of them have their time and their place and it is about finding the right mix and selection.
So how to select? By trying out methods, by learning them, succeeding and failing. This is how I learn, and I assume that is true for many people.
Another question I pondered was to understand, as to why many people, whom I think of as most accomplished in the field of software testing and software quality, are that strongly opposed to ISO 29119. They are most likely the ones who know most about the methods and tools available.
And I went back to the way I learn. And when looking back, I learned by example. By emulating, by following a script, a schema. By following a script, a step by step guide you learn a method without actually deeply understanding it. Just over time, as you use it more often, experiment with it, observe what happens when you deviate, you learn not only to use that method, but to inherently understand the method. And the more you understand it, the more you will forget about the script. The more you understand it, the more you will use the method based on your understanding of the underlying principles. And the more you understand it, the more you will see the shortcomings of the script, the simplifications, the things left out just to make it palatable.
This reminded me to the discussions between Kent Beck, David Heinemeier Hansson and Martin Fowler on TDD. There one of the arguments of DHH was that the methods of TDD would at some point actually hurt the design. Kent Beck on the other hand argued that he works from first priciples and therefore it should not hurt the design.
And throughout the discussion one thing became evident: that the mastery of a technique will also come with the knowledge of its shortcomings and therefore with the knowledge of what to do when, not to use a simple if that approach.
When publicizing methodologies, or more importantly, popularizing methodologies, things tend to get a little bit more complicated. To enable others to learn, simple schemas are created, which are easy to follow. Examples are created, as to show how the application of a method can work. Often the underlying principles are omitted for the sake of simplicity and clarity. And, sadly enough, the simplifications can win over the underlying principles.
It is a fairly easy to understand and easy to explain rule to write testcases in a way, that the function you test is completly isolated, independent of other parts of the code. This will affect the design, as the developer will write his code to make that as easy as possible. The problem is: if the design for the test wins over the design for the function of the program, something is actually wrong. This is even more true, as the “rule” which requires these design changes in itself is wrong, because it is overly simplified and was never intended in that way.
I find the situation similar with “agile” and “SCRUM”. Many people obviously do not know, that these are actually two different things. Many of the same people would shout “no, we have no rigid processes, we are agile, we do SCRUM” while following the book slavishly, meticulously and to the comma, applicability nonewithstanding. I see some irony in there.
So I wonder: might it be the case, that the more we learn and understand, the more we abhore the scripts, the schemas, the oversimplifications? Might it be that with all the background knowledge we see all the errors in them and want to prevent “beginners” to start “with a flawed script”, even though we started that way ourselves?
Or is it just the way that we do not want some people to sell oversimplifications as “the real things” to people starting the craft?
I for myself am not completely clear about it. But I tend to think it is the latter, as it is one thing to start with the basics, and to teach a script at start, and another to teach the script as the whole and only truth.
I conclude that everybody should remember that the world is a compex and complicated place. As a physicist I have learned, that even simple models are helpful and can allow for predictions. But as you learn more about the systems you model, you learn about the subtleties, the higher order effects, the non-linearities and so forth. And as a physicist you learn to remember that you talk about a model, not the truth. A model, which has its use and has its boundaries.
The world is complex and complicated. Easy and straightforward solutions therefore will only bring you that far. Therefore always remember to dig deeper and beware of oversimplifcations.
This post is also available in: German