Agile Methodology- Process vs Anti-Process

Survic wrote very interesting comments in response to my observation on Rockford Lhotka's blog.


Since Survic has not recorded in his blog, I am reproducting it in my blog :)

Survic Wrote

Vikas said: “At least, it is giving some structure/discipline/framework where none existed”.

That remind me a weird observation of TDD in .net.

Basically, it is the downside of the same fact that Vikas pointed out.

In java, TDD represents the lightweight force -- it attracts guys who are tired of heavy process stuff. As a result, most practitioners in java TDD tend to cut corners: 100% unit testing, GUI unit testing, property unit testing? -- shut up and give me break! That is so “natural”; that goes without saying: come on, this is XP!

However, in .net TDD attracts guys who can waste time!!! -- I am sorry to say this, but it is the insight I got after a lot of surprises I got from .net’s TDD guys – TDD in .net represents process, not anti-process. It is very weird and sometimes even shameful and dishonest, in the sense that TDD is anti-process -- how can a person abuse TDD to drive the agenda to create a heavy hierarchy!

This weirdness in .Net TDD is that classic VB’s RAD is much more lightweight, so, people who likes lightweight will not be attracted to TDD. And people is the determining factor of a (sub)culture. So, TDD in .Net is pro-process!

Combining the above factor with another factor that TDD, by its default configuration, is against consulting designing, it is no wonder a person who is working on consulting framework design, and has a healthy dose of classic VB RAD sense, will be antipathy about TDD in .Net.

I am with you, Rocky ;-)

I was not sarcastic when I say “I am with you” ;-), let’s me explain:

1. We can re-interpret XP/TDD to such way that it supports or even requires using framework. It is really very simple: using a “metaphor” in XP/TDD really means picking a framework among a few well-known frameworks. Consulting in design phase means to establish the “metaphor” for a project. It requires tear apart well-known frameworks and combine those parts together.

2. The pro-process factors, which are minimal in XP’s origin (small talk), and are still heath in java (because it is fighting with heavy processes), become absolutely ridiculous in .Net -- because XP/TDD is actually fighting the classic VB RAD, go figure! So, it is right to cut those pro-process craps in TDD in .net.

Conclusion
I think that Survic has made very excellent, thought-provoking observations. After reading this, I think that I know why I have reservations about using extreme programming for a industrial-strength software (because of my process oriented bias).

I think that neither anti-process morts nor process-oriented purists are going to embrace extreme programming in .Net arena, it is going to restricted to a small cult of programmers ( I would definitely use it for short term project)

For record, I do use a hybrid of Agile and Waterfall Methodologies very successfully.

Note: I am going to refine my thoughts