Good sentiment. I'd add that you should do more than think and reflect in our industry. Go out and try it. (And try hard.) I find it hard to form an educated opinion on something until I've played with it myself.

Absolutely.  Accept nothing at face value, especially things like "You can't write quality code without testing."

:)

Merry Christmas.

I agree to a certain extent. The problem is that if people who are unqualified to make decisions on how to develop applications start thinking that they know a "better way", then when do you start to defer to the experts who have written seminal works in this area? Honestly, whenever I feel like I know how to do something in a better way, generally speaking I don't understand the topic. :-)

@derik: I agree. A corollary might be that doing DDD bad is still better than doing nothing (like some crazy home-grown ORM or "Data Access Layer" crap)

@jdn: "You can't write quality code without testing."

You can, but how are you gonna prove it?  I don't trust you or any developer. Show me the proof. Tests happen to be a good way to do that.

Evans book changed the way I think about (and develop) applications - nonetheless, I've also noticed the same disturbing tendency to treat anything Evans says as "gospel", even going so far as to quote him chapter and verse.

Casey Charlton has a great post on the "spirit" of DDD ( devlicio.us/.../the-tao-of-domain-driven-design.aspx ), and I even had my own Road to Damascus experience ( blog.quiziqal.com/.../Domain-Driven-and-Not-a-Repository-in-Sight.aspx ).

Thanks for adding some much needed perspective for anyone who finds themself becoming a "one book" ( en.wikipedia.org/.../Homo_unius_libri ) developer.

@Chad

As you might say, I've seen it dozens of times.  You can write quality code without testing.  And, prove to me your tests are good.  Even Code Coverage 2 says studies prove testing code has more bugs than the code it is testing.

I'm in favor of testing too.  I just don't have the religious zealotry about it.

As the one who made the comment in question, I agree wholeheartedly with this post. Only you, the implementer, can decide what is right for your particular situation. Thinking for yourself is key.

However, this is the tension between between generalization and specialization. At what point do you begin to stand on the shoulders of giants?

A guideline I use sums up Justin's comment: "If you are being clever, you probably don't see the whole problem."

You are most likely tenacious in your readings, questionings, and understandings. Leave room for that tenacity in others as well; let them be innocent of zealotry until proven guilty.

@jdn: [Sincerely] Please stop with the insulting remarks (i.e. 'zealotry'). It doesn't help with the debate/argument. You may be mistake Zeal for rigor/discipline.

Perhaps we see testing as more than just ensuring something is correct?  It can also serve as a way of keeping the design process focused and on-track, it can serve as as sort of guide for maintenance programmers in the future, it can serve as safety locks and canaries-in-the-mine for future changes, allowing us to proceed at the same pace of writing quality code.

Sure you can write quality code without tests, but I contend that you won't be able to continue writing quality code without tests for very long.

Put differently the friction/cost/problems grow exponentially as amount of code produced increases.   Without effective measures to manage this, eventually the friction/cost/problems become prohibitive and the system becomes effectively "unmaintainable" (in the same way an otherwise operational car can be considered "totaled."

In my experience, rigorous testing, especially test-driven, tests-are-first-class-code-citizens type tests, are the most effective way I've yet seen to manage this ever-increasing cost/complexity.

@Chad

I won't stop using terms like' zealotry' until people stop being zealots.  And yes, I know the difference between zeal and rigor.  And, frankly, you are well known for feeling insulted at the drop of a hat.

"I contend that you won't be able to continue writing quality code without tests for very long."

See, this is BS.  We wrote code in the 90s using VB6 COM and SQL and tested the 'old-fashioned' way, manual clicky clicky.

Do I have any particular desire to go to those days?  Hell no.  But the quality of the software was good.  It was maintainable (though not as maintainable as what we can do now).

It's like when people (like you for instance) say you can't do data driven architecture well.  It isn't true and leads one to think about zeal.

Software has been written for decades without the tooling support we have now that makes testing easy (and no, the fact that some SmallTalk developer wrote a white paper whenever isn't relevant), and makes B/TDD a reasonable set of methodologies to practice.  It is categorically false to suggest that there was no quality software then or that you cannot do it now.

You can continue to disagree all you want.  I will continue to argue that zealotry about alt.net themes hurts the cause as much as it helps.  Telling people it isn't possible to write quality code without tests is false, and hurts the cause of getting people to write better code with the aid of testing.

Oh, and people should read this as well.

ayende.com/.../the-tests-has-no-value-by-themselves-my-most-successful.aspx

I willing to bet that Ayende knows something about testing.

You've been kicked (a good thing) - Trackback from DotNetKicks.com