Scott Hanselman

Hanselminutes Podcast 163 - Software Metrics with Patrick Smacchia

May 28, '09 Comments [6] Posted in Learning .NET | Podcast
Sponsored By

419346614_2444548850 My one-hundred-and-sixty-third podcast is up. Scott sits down with Patrick Smacchia, lead developer of NDepend, and talks about Software Metrics. What metrics lie beyond Lines of Code?

Subscribe: Subscribe to Hanselminutes Subscribe to my Podcast in iTunes

Do also remember the complete archives are always up and they have PDF Transcripts, a little known feature that show up a few weeks after each show.

Telerik is a sponsor for this show!

Building quality software is never easy. It requires skills and imagination. We cannot promise to improve your skills, but when it comes to User Interface, we can provide the building blocks to take your application a step closer to your imagination. Explore the leading UI suites for ASP.NET and Windows Forms. Enjoy the versatility of our new-generation Reporting Tool. Dive into our online community. Visit www.telerik.com.

As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)

Enjoy. Who knows what'll happen in the next show?

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Thursday, May 28, 2009 6:50:01 AM UTC
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?)
Friday, May 29, 2009 7:00:48 PM UTC
Mr. Smacchia has quite the accent.
Hard of Hearing
Saturday, May 30, 2009 1:10:37 PM UTC
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.
KevDog
Friday, June 05, 2009 6:23:43 PM UTC
I think I will read the transcript instead. It was very difficult to understand Patrick.
Hard of Hearing too
Wednesday, June 10, 2009 3:32:08 AM UTC
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…).

Wednesday, January 13, 2010 5:02:24 AM UTC
its really good to know this information its would be thankful
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.