The Most Complex Thing That Could Possibly Work

When I read first eXtreme Programming explained of Kent Beck, it sounded to me like an evidence that we have to do the Simplest Thing That Could Possibly Work. Where is the trap? Don't we are all aware that making things simple is the best way to be understood? In every day life, it seems it is true. We seek first to understand then to be understood. Hum...

Later in the book, I began to catch what he really means:

It's hard to do simple things. It seems crazy, but sometimes it is easier to do something more complicated than to do something simple.

The irony of trying to make things simple is that it is often simple to make things complex and complex to make things simple.
I nearly experienced this, and it definitively convinced me that, in certain cases, it is a real waste of time to try to explain why something looks complex while an easier solution could work.

It happened with the agile process group in my firm, the group I talked about in a previous article. Let me present what shocked me.

Test-driven-development is one of the XP practice that helps making things simple and designing in small steps. As the agile group tried to define completly the agile process, they had finalize a schema, that I changed a little to be allowed to show you the result:



Waouh! Arraws everywhere, boxes, lot of texts! I immediatly felt bad about it. Who wants trying to do TDD when it makes you several minutes before understanding what it is? Maybe it's me who hadn't understood TDD? So, I went back to my books, I seeked for information on the web, and tried again to define what is TDD. My research conducts me to my first feeling: this schema is the Most Complex Thing That Could Possibly Work to explain TDD.

For those who discovers TDD, I made an other schema:


I think no other word is needed to explain TDD.

Unfortunatelly, my proposition has not been kept for several reason. First, because it cames from me. The person who mades the complex shema, someone I sincerely respect, do like being the owner of everything. Secondly, because this person had never really practiced XP (only a few monthes) and from my point of view, didn't caught what being agile means. Finally, because it was not complex enough. His value system says that he can only be impressed when things gets complicated. He is an engineer! His work is complex and consequently, what he has to show must be complex.

I tried to discuss... And I wasted my time. Now, I gave up the working group. The energy required to be heard costs too much and there is no gain. I prefer concentrate myself with my team, which will continue over any process to be agile.