Having said this, indeed, most of the people that actually shipped features faster then any other don’t know who Joel his, who Ken Beck his, Martin Fowler etc etc. Know little about TDD etc etc. So this just might be telling us something about it, they are just smart and skillful.

Usually software development advances start with a great idea gathered from the experience of one or two people. An idea that worked for these people in particular circumstances. Then depending on ones garble ability it may gather some followers. Usually we hear about successes, rarely failures. Followers try to justify failures due to malpractice. After awhile ideas are sold has packages of concepts. “If you do this you will be great”. This sells conferences, books, training etc.

If week keep our focus at the core of ones idea, if it is any good will help us to create our own ideas to handle our own situations. It is easy to keep focus, just switch off the soft dev radio and do some work.

As an IT consultant working for fortune companies never had the opportunity to use TDD. The reason why I never got excited is because proving that a software works in code requires has much effort and thought has coding the software itself.

The problem is that quite often I’m not payed to write the software and its inverted version. User tests are usually just enough.

a = b
assert.equals(a,b)

Sometimes this is necessary, sometimes it is not.

On another note I think it is only natural that writing tests helps write better software. It is like someone writing the same book twice … then again the second book may not come has good has the first one. Should this come as a surprise?

In the world I live usually we can only write a peace of code once. Rarely we have the opportunity to write it twice. Three times, no way.

Here is a tip: Exercise designing and writing code once and bug free. That is the ultimate time saver. That is the skill speed deamon’s have. Like any skill it can be learned.

Cheers,

Nuno
PS: By the way. I am a programmer and I would love to do TDD with 40% coverage. If you have a project where customers have pockets deep enough or software is critical so that I can use and learn it fully send me an email. Then again I might not be experienced or smart enough to be of help.

I wonder how TDD sees the eventually consistent ideas. Should I test for inconsistencies, consistencies or both?

Now I see that Joel is having another dig at unit testing on his blog entitled, “The Duct Tape Programmer”.

Uncle Bob Martin’s response:
http://blog.objectmentor.com/articles/2009/09/24/the-duct-tape-programmer
was followed up by a comment that I found most interesting:
“never take software advice from a bug tracking system salesman”

TDD isn’t about testing, it’s about the way it makes you think about how you design your system and reduction in maintenance cost that stems from that.

WTF?

Don’t bother, really. Joel is a good writer, not a programmer. He just not worth it.

Regards,

Slava Imeshev

One might sit there staring at an array of ExpectedException(typeof(ArgumentNullException)] tests and think…. is this really necessary? Does this confer a benefit greater than that of writing such a test?
Its this type of diminishing return that signals that some people don’t know where to stop. I speak after just removing some interfaces from a design that required transactionality across a number of objects. Their creation was misguided and done blithely. Internal classes were all that were required at this stage.

These people who implement the rules blithely encounter people like Joel which makes Joel comment like this. But he is mistaking their words for yours and this is probably where the misunderstanding lies.

In practice I find that quite a number of developers create unit tests that are redundant, expose internals horribly or just don’t test things properly. Its output like this combined with the selling of books and hype that create skepticism that turns into such criticism.
The huge wave of Agile in the early to mid 2000s were the precursor of a backlash of some sort in the very same way the US swings between Demopublicans and Republicrats.

I would trust that if the people in question were to meet personally the disagreements would not occur. They occur due to the mis-appropriation of the knowledge by fanboys, people assuming that the fanboys are carrying the message of the original author when they may have made their own modifications, abbreviations or lost some in translation.

Kent – you are truly awesome.

I think his point is summed up with his statement towards the end fo the clip that “The way real software works is that you create these very imperfect things, and they work great. They really do. And then you have a little problem, and you go and you fix the little problem, because it’s code, and you have an editor, and you edit it.” I think this is fine when you are working on small projects and maybe have plenty of time to fix these problems in between gearing up for the next release. Without a certain level of quality, how can you predict the level of support needed for your code?

I certainly also think he underplays the power that a comprehensive Junit test suite gives you “the ability to change things in their code with the confidence that they don’t break anything”, this is certainly not some throw away thing.