How come that many of us developers are struggling with agile methodologies like test-driven development or componentization/modularization of a software?





I was asking myself this for a long time now. Being an agile coach I frequently see developers fail applying these techniques in their daily work. Intelligent people that are able to write code to take care of the most complex problems around. And yet an apparently simple technique like write-your-test-first doesn't get a grip with them. Why?





In the past I tended to blame the workload and pressure of management and the urgent need to put out the next feature and QA it afterwards that somehow caves in the people into this treadmill of assembly-line work like feature production. In this treadmill they are not able to get the time or freedom or even will to learn something new, to question what they are doing, or how they could do better.





It's easier to just do what one has always been doing for this they would know, this would require less efforts and less energy. Change on the other hand comes with i nconvenience, with insecurity, with the need to work more consciously which slows down compared to working with a routine.





So, changing the approach developers use to get their things done becomes a long hard process. Sometimes it feels like a behavior therapy with me being the therapist.





But I get carried away - a bit.





Just recently I came up with another source of evil, though: Textbooks!





I was curious about JavaScript and node.js recently. What would you do to get a concise guidance on any new language? Well, me I would buy a good book and work through it - or google a good tutorial on the web or something.





This time though I wanted something else. For me being an agile coach I wanted to do what I am preaching. Do TDD right from the start. So I skimmed through the pages and in the index I found "Testing" at page 10-something. Wow! I thought. There is something about testing and it's quite early in the book.Promising!





Well. what a disappointment. It simply suggested to create an index.html file where the JavaScript would be written to or linked and to open this in a browser to witness the effects of my changes.





That's all to it.





After this the whole thing was like every time: Gradually introduce the language and write some code to learn it.





That way I learned some other languages as well. It never ever crossed my mind that I should write some tests first. Instead I wrote a few tests afterwards. Just like the others did. Fine!





No!





Thousands of young people learned their first programming language that way. They did not learn about testing. They got the notion that programming meant just writing code that accomplished the task at hand. Then they would discover that there are bugs in what they wrote and they learned how to debug even nasty code. Some of them are rather skillful debuggers and learn about seldom used features of their tools. They feel like the best programmers around for they would nail down even the strangest bugs. Bug fixed. Fine. No test needed. The bug has gone, hasn't it?





I've seen many of these guys entering corporate software development where they would move along their way and would just hack on a bigger scale.





Try to tell these people that there are other ways of doing it. They imbibed programming with no testing from their infancy. It's hard to change something about it. They would lack the awareness of potential problems with that approach.





I'd plead for a new style of textbooks.





It came to my mind that the textbook I would like to read (or even write for that matter) would be different. I would like to introduce a language TDD style. Explaining testing first. Why not writing a HelloWorldTest first? It's a program as well, isn't it? It's a minor change of perspective but a huge change in mind.





Tell you what, while thinking about this idea I stumbled across this book on node.js:





To my big surprise it did exactly what I would like to do: it started introducing node.js with TDD. Thanks for providing this enlightened little book!





Read also:





The opinions expressed in this blog are my own views and not those of SAP