Scott Hanselman's ComputerZen.com

Oo can't wait to hear this one, NDepend is such an awesome tool!

Feel free to do more shows on code analysis! Also, what about diving into IL? For instance, to speak of IL manipulation tools and so forth, which seem to be relatively scarce in the .NET space compared to Java(?). Mono's Jb Evain might have something interesting to say. And how come you haven't interviewed Lutz Roeder? (You haven't, have you?)

Mr. Smacchia has quite the accent.

Patrick is one of my programming heroes, I was very excited to see that you did a session with him. He's like some sort of exotic French Musketeer Code Ninja.

I'll have to listen to this one a couple of times, not because of his accent but because of the number of ideas I got for improving code while listening to the podcast.

I think I will read the transcript instead. It was very difficult to understand Patrick.

Hi,
It was a very good podcast with Patrick. Thanks for that. I have downloaded NDepend and it looks like a great tool. However, pretty complex at first glance; I think I know what would be my hobby for the next couple of weeks. I also believe that we should have more than 2 weeks for a commercial trial. The tool is pretty complex and I believe it takes more than 2 weeks to get around it (especially if it is not your only task).
I would like to point out something Patrick said in the podcast on which I do not totally agree…
At a certain point Patrick talked about the case where you have a popular class to which many other classes are coupled and he suggests that in this case we should change it to an interface even though it will have just one implementation.
While I agree that we should sometimes use interfaces in order to decouple certain pieces of an application, I believe that we should not push this principle to the extreme. We should use interfaces when we need an interface; either for testing purposes or for decoupling because a layer or a block of the application may be replaced later (that is especially true for commercial software that is open for changes - customizable -).
If we take the example of a utility class for instance that is pretty popular and used in many other classes; well, if I make it an interface that means that everywhere I need an instance, I have to call a factory method knowing that it will always return the exact same type of instance. Another caveat is that as you start to use interfaces, you forget about the 'go to definition' context menu in Visual Studio (which I found very useful). In other words, following the code (not at runtime) is not easy as the type of the instances is only known at runtime. What about these 'popular classes' that have many static methods?
I believe that some classes are made to be very stable (usually implemented in the first iterations of the project because they are part of the foundation) and thus can and should be used directly (strong coupling). No need to decouple them. Think of all classes of .NET framework that we use directly;
That is said, nowadays, we often hear architects (not pointing this podcast specifically) pretending that we must decouple everything; I have heard many times the statement 'We must use only interfaces between applications' layers.’ From my perspective, decoupling by abstracting the classes (using interfaces) must have a concrete purpose otherwise it is just impacting your productivity for nothing. By concrete, I mean a reason that has an ROI associated with it or a strong technical reason (testing can be a good reason; an application that uses the provider model for instance - pluggable blocks - etc).
Thanks again and hope to hear more podcasts on this kind of topics (design, software quality…).