TDD on One Page

This drawing is part of a Leanpub book: https://leanpub.com/agileplanet. If you like it, you might want to have a look at the book, too.

References:

• "Test Driven Development by Example" - Kent Beck
• "The Pragmatics of TDD" - a blog post by Robert C. Martin (Uncle Bob)
• Wikipedia on Test Driven Development

Testivus zum Thema Test Coverage

vor einigen Tagen bin ich auf eine nette Anekdote zum Thema "Code Coverage" von Alberto Savoia gestoßen. Ich finde die Geschichte so gut, dass ich sie gerne ins Deutsche übersetzten möchte:

Testivus zum Thema Test Coverage

Am frühen Morgen fragte ein junger Entwickler den Großmeister:

"Ich würde gerne ein paar Unit-Tests schreiben. Welche Code Coverage sollte ich erreichen?"

Der Großmeister antwortete:

"Mache Dir keine Sorgen über Code Coverage. Schreib einfach ein paar gute Tests."

Der junge Entwickler lächelte, verbeugte sich und ging.

Später am Tag kam ein zweiter Entwickler mit der gleichen Frage.
Der Großmeister zeigte auf einen Topf mit kochendem Wasser und sagte

"Wieviele Reiskörner soll ich in den Topf werfen?"

 Der Entwickler schaute ein wenig verstört drein und antwortete

"Wie soll ich das sagen können? Das hängt doch davon ab, wieviele Personen davon essen sollen, wie hungrig sie sind, was sonst noch an Essen angeboten wird und so weiter."

"Genau."

sagte der Großmeister
Der zweite Entwickler lächelte, verbeugte sich und ging.

Gegen Ende des Tages kam ein dritter Entwickler und fragte die gleiche Frage zum Thema Code Coverage.

"Achtzig Prozent und nicht weniger!" 

Antwortete der Großmeister in hartem Ton und schlug mit seiner Faust auf den Tisch.
Der dritte Entwickler lächelte, verbeugte sich und ging.

Nach dieser letzten Antwort ging ein junger Auszubildender auf den Großmeister zu:

"Großmeister, heute habe ich gehört, dass Sie auf die gleiche Frage zum Thema Code Coverage mit drei verschiedenen Antworten reagiert haben. Warum?"

Der Großmeister stand von seinem Stuhl auf:

"Lass uns einen guten Tee trinken gehen und darüber sprechen."

Nachdem sie ihre Tassen mit heißem grünen Tee gefüllt haben erklärte sich der Großmeister:

"Der erste Entwickler ist noch neu und fängt gerade erst mit dem Testen an. Momentan hat er eine Menge Code und keine Tests. Er hat noch einen langen Weg vor sich; sich zu diesem Zeitpunkt auf Code Coverage zu fokussieren wäre nur deprimierend und recht nutzlos. Er wird weiter kommen, wenn er einfach übt gute Tests zu schreiben und auszuführen. Über Code Coverage kann er sich auch später noch Gedanken machen.

Der zweite Entwickler aber ist schon recht erfahren mit Entwicklung und Testen. Als ich ihn gefragt habe, wieviele Reiskörner ich in den Topf werfen soll habe ich ihm geholfen zu verstehen, dass die Menge von Tests abhängt von der Anzahl und dem Gewicht verschiedener Faktoren. Diese Faktoren kennt er weit besser als ich - es ist immerhin sein Code. 

Es gibt nicht die eine richtige Antwort und er ist clever genug mit dieser Wahrheit umzugehen und damit zu arbeiten."

"Ich verstehe", sagte der junge Auszubildende, "aber wenn es nicht die eine einfache Antwort auf diese Frage gibt, warum haben Sie dann dem dritten Entwickler gesagt: 'Achtzig Prozent und nicht weniger'?" 
Der Großmeister lachte so herzlich und laut, dass sein Bauch - der darauf hindeutete, dass er nicht nur Tee trank - auf und ab wippte.

"Der dritte Entwickler will nur einfache Antworten hören - auch wenn es keine einfachen Antworten gibt ... und am Ende folgt er ihnen dann sowieso nicht."

Der junge Azubi und der grauhaarige Großmeister tranken ihren Tee in nachdenklicher Stille fertig.

Hier noch einmal der Link zum Original-Blog.

Organizational Dept

In the field of software development, there is a metaphor called "technical dept".  In short, this metaphor says that while you are programming you almost always build up dept. Dept in this case means that your code base decreases in quality over time. You will have to invest time and work to amortize this dept. If you do not amortize your dept, interests will take effect. Thus, as with regular dept, you will always be better off to amortize the dept as soon as possible. Otherwise compound interest will be the effect and at the end you will pay heavily - if you are able to pay back at all anymore.

Speaking about Agile transformations there is another kind of dept. I would call it "organizational dept". It is based on the same concept as technical dept but on an organizational level. As your organization grows, you will take hundreds of decisions. Not all of them will be perfect and thus, you will (with every decision) increase the organizational dept. How does organizational dept look like?

There are multiple instances of organizational dept. Just to mention a few:

• People in the "wrong" position (on jobs they are not suitable for)
• A wide gap between the culture wanted and the culture existing
• Unresolved conflicts between people
• ... and many more ...

As with technical dept, if you do not regularly and fastly cope with organizational dept, interests will occure and over time compound interests will make your dept almost unbearable. At some point you might not be able to pay back at all anymore! Speaking of technical dept, the consequence for a software system is then to be displaced by a new system. What do you think will be the consequence for a company if you get into this state with organizational dept...? I think, we all know!

This is one point why Agile is so successful. Agile folks generally reject living with dept and always try to pay back as soon as possible. The incarnation of this attitude is e.g. the retrospective in Scrum and the focus on continuous improvement and impediments in all Agile methodologies.

Update: Sven Winkler picked up the idea of organizational dept on Boris Glogers Blog and adds some interesing points of view.