A while ago I was trying to explain the benefits of Castle to developers, and I just couldn't get through. It is pretty easy to explain the benefits of using Active Record, but I had a hard time explaining MonoRail and Inversion Of Control.

Here is my elevator speach for MonoRail:

I got into a lot of problems with this, since it doesn't convey the benefits to the people I am talking to. The response that I got where:

• RAD without wizards? There is no such thing.
• MVC? Front Controller?
• I already has seperation between the UI (aspx) and the Business Logic (aspx.cs)

I can show how quickly I can create a page, but it will seem slow compared to doing the same thing in VS.Net, since I don't have a designer to "help" me. How do you explain the benefits of design patterns to those who doesn't feel the pain*? How can I explain the benefit of strict seperation to those who think that aspx / aspx.cs is good enough seperation?

I got the same problem when explaining Inversion Of Control, they couldn't get why they shouldn't just use new. Do you think that those things, like bicycle riding, can only be understood by actually trying them?

I know the motivation parts of those patterns, but I don't think that I managed to make the people I was talking to get the advantages of this new way of doing stuff.

* Those Who Doesn't Feel The Pain - I like this pharse.

I was testing using NHibernate in ways that I never did before*, and the test kept failing. Each time I would fix one thing, and another part would break. It wasn't very obvious how to make it work. I had a guy watch over my shoulder while I worked throught the kinks of the problem. After the test failed repeatedly for the 10th time or so he just muttered something about "never making it work right" and walked away to do something else.

To me, TDD is all about failures. I know that I need to do something only when I get a failing test. And the failing test kept pointing me to this error and that error, and I kept researching and fxing the errors. Eventually I had enough understanding of what I was trying to do and how NHibernate was trying to accomplish it that I could get it to work (perfectly). All in all, it took about 30-40 minutes of trying.

I am not upset to see failing tests, they are the best sign that I have that something is wrong.

* Highly complex schema with some indirection thrown in to add to the mix.

One thing I really wish that I could do is to make the debugger use Reflector if it can't find the source files for an assembly. This would be a nice way to track problems into the framework (or other libraries). This is what I have to do today, but I do it in my head, which doesn't really work.

It is common to people that are starting use O/RM to get into a situation that they don't know how to solve using the O/RM (or even aware that such a thing is possible). The easiest example is loading just Id and Description for a certain class without loading all the (possibility expensive) properties.

There are several ways to do this using most O/RMs, but they are usually not obvious to the beginner. This is usualy a pain point since they can easily see how they would do it using plain SQL, but they either don't know how to use the tool appropriately, or they just don't think this is possible using the O/RM. The immediate solution to that is to just use plain SQL (or SP) to solve this one problem.

It is wrong because it pokes big holes in the model you show the rest of the system. If means that the model that most of the system is using doesn't match the model that the rest of the system is using.

This is bad because you lose of of the key benefits of using O/RM, abstracting the database. A good O/RM will always let you work against the objects structure, not the data structure. This is important because it frees you from dealing with a potentially ugly schmea and work with a good model all the time.

In nearly all the cases, you can use the options that the O/RM gives you, and get what you need without dropping to SQL. That is not to say that SQL isn't important. It is very important, because O/RM tend to be leaky abstractions, it is just that you shouldn't reach to the familiar tool when you need to solve a problem without an immediate solution.

What I'm more afraid of is that using SQL to solve the immediate problem will start to spread through the code, since "it is already the way we did it in XYZ". And that is a whole new can of worms. Letting this spread means that you effectively have two data access layers for a single application for the same model. I trust that I don't need to explain why this is bad. Just the syncornization between the two will be a pain, and considerring the way the SQL Access Layer is likely to appear (growing from quick solutions to problems), I am willing to be that it is not going to exhibit good design (at all levels).

If you really need to use both, make sure that you investigate the options to solve the problem using the O/RM first, and then make sure that this solution goes through the front door with all the bells (Design, Tests, Code).

Rocky took the time to clarify his comments on TDD in dotNetRocks #169. There seems to be a couple of main points there:

As a testing methodology TDD (as I understand it) is totally inadequate... ...the idea that you’d have developers write your QA unit tests is unrealistic

TDD is not a QA methodology. TDD is about designing the system so it is easy to test. This makes you think about what the code does, rather how it does it. The end result is usually interfaces that are easier for the client to work with, coherent naming for classes/interfaces/methods, the level of coupling goes down and the cohesion of the system goes up. Then you run the test.

The idea in TDD is not to catch bugs (although it certainly helps to reduce them). The idea is to make sure that developer think about the way they structure their code before they start writing it. It also means that developers has far more confidence to make changes, since they have a test harness to catch them if they break something.

You start with a single test, to check the simple case, then you write another test, for a more complex case, etc. The purpose is to assert what you are going to do, do it, and then verify that it does what you assrted it should. QA isn't going away in TDD, for the reasons that Rocky mention in his post (developers rarely try to break their app the way a Tester does). QA and Developers takes two different approaches. When I get a bug from QA, I write a failing test for this bug, and then I fix it. Now I got a regression test for this bug.

When I touch this part in 6 months time, I can do it with confidence. I know that I will not:

• Break any of the assumtions of the original developer - I got tests that verify that the original functionality works
• Regress any bugs that were found before - I got tests that would verify the bug is fixed.
• Any future maintainer of the code will not break the sutff I'm doing now - I write tests that will verify that the new functionality is working.

Those and clear design are the main benefits fo TDD, in my opinion. Again, I agree that this doesn't remove the need to have QA team that hates the product and really want to break it :-).

CRC is cool, I agree, but the issue is how detailed you go. I can probably think of the major classes that I need for a project up front, and maybe even come up with their responsabilities and some of the collaborators. Until I sit down with the code, I can't really say what methods and what parameters will be at each class, what other stuff I need to do this work, etc. TDD is about the interface/class/method design, not directly about full system design (although it will influence the system design for sure).

This is something I really do not agree with. If you don't use TDD to influence your design, you are not doing TDD, period. You may have tests, but it's not TDD. Writing tests after the fact means that you don't get to think about what the client of the code will see, or use things that make it much harder to test the class. You lose much of the qualities of TDD.

What you end up with is a bunch of one-off tests (even if they are NUnit tests, mind) that doesn't cover the whole system, and are only good for testing very spesific things. They don't affect the design of the code, which can lead to very cumbersome interfaces, and they don't cover the simple to complex scenarios. They may represent several hours (or days!) of programming effort that culimate in a long test that test very spesific scenario. Those are integration tests, and while they have their place, they are not Unit Tests. NUnit != Unit Tests.

And here is a reply to some of the comments in the post:

Sahil Malik commented:

You do not stop debugging, that is correct. It does mean that you have a very clean arrow that points to where it failed, including the details, so you have much easier time to fix it. And having an army of tests to maintain would be bad if they didn't have an army of code that they test. Yes, tests has bugs, and the code has bugs, but the chance that you would get the exact same bug in both the test and the code is not very high. When you will see the test fail, you'll investigate and discover that the code is correct and the bug is in the test. No need to write TestTheTestThatTestTheTest... scenario.

I just noticed that emails that goes to the Junk E-Mail in Outlook are displayed as plain text, and that the links there are not working. That is, they are clickable, but they won't take affect (it was annoying to find this tidbit, because it looked like it should work).

The question is actually very short: Why?

I just saw an obfuscation package for .Net that goes for over 600$, and I'm not sure if that is per developer or not. I know that there is this belief that obfuscation will protect your IP, etc, but I fail to see the point in this endavor.

I can see several scenarios for wanting to obfuscate the code:

• You are a component vendor and you don't want people ripping you work and using it elsewhere.
• You ship a product out and fear that people will decompile your code, remove the registration routine and re-compile it.
• Your code contains classified information or secret business logic.
• You think that it is your code, and I have no business looking in there.

For the component developer:

What is valuable is not how you do that trick with triple buffering or custom event handling, or the Ajax capabilities, or whatever. What is important is that the whole component mesh well with the rest of the envionment and that it is easy to work with. If I got a problem in your component I will go into Reflector and try to find what is wrong. I will be seriously pissed off if I can't figure out that I should've prefixed a \ because the code is obfuscated. If someone is going to rip you off, obfuscation isn't going to help, if they need to take the whole thing as a black box, they will. And then were you are?

I'm going to use maybe 10% of the capabilities of what you give me, if I'm going to have to fight it, I'll rather just roll my own, it's simpler to do so and at least I can control what is going on.

For the obfuscation will make it harder to crack my product:

No, it won't. I can run your product under the profiler, find the path of calls that blocked me, and just return "true" from the IsLicensed() method. It's a lot of work, and in general, I have better things to do with my time than break products when I can just pay for them. That said, there is a certain class of people that enjoy this challange, and yet another section of humanity that uses their labor to use your labor without paying.

Obfuscation only make the game more interesting, and considerring that obfuscation doesn't change the meaning of the code, it all turns into a mental challange similar to this. At worst, they will just check the x86 assembly that is being JITed and see what you are doing in that level.

For the classified information / secret stuff in my code:

What are you doing giving away your confidential data to the users anyway? If it is really secret, then you should put it somewhere you control, and only let people access it if they are authorized. Putting the classified information in the client just means that A) they can access it if they need it and B) they likely to do so without you knowing so. If it is secret, you should keep it under lock. The moment it is in the hands of the users, it is only secret as long as no one tries to find it. If it is not really secret, than it's either #1 or #4.

For the guys that thinks that I shouldn't look at their code:

You code is not likely to be anything speical, sorry. I regulary goes over libraries I use with Reflector, it's a mini code review that I do, mostly to familiarize myself with the library and the options that I can use. Several times I rejected libraries because the way the structured their code, under the assumstion that if they did such a bad job in this, it's not going to be easy / fun to work with the API that exists, and the general quality of the code isn't going to be stellar (to say the least).