Tuesday, October 31, 2006

The Big Move...

Well I've been in a moving state for over a week now. We weren't planning on starting our move until last Sunday but then "The Crickets" started to make their presence known and it was time to get out of dodge.

Jeremy Miller makes posted his Programming Manifest and I have to say I agree completely. Very well done.

I've actually been having some really good discussions with a contractor of ours lately. It's interesting because he is old school so he provides some good counter points to the "interface based" design that is so popular these days. It's good having different views so you can decide what makes the most sense to you.

Sunday, October 22, 2006

Testing.. Why not involve a client?

Fellow Edmontonian Igloo Coder brings up a few very good points about testing. The most valuable every experienced developer knows by now and every new developer should know..

"Developers don't make good testers. Because of this, don't rely on them to do your only testing"

One thing he doesn't mention is that part of the problem is ego. Most developers have some sort of ego (generalization I know.. I've seen truely great coders with no ego.. and others with an insane amount of ego..) which makes it hard for them to believe that the piece of code they just wrote isn't the best coding every done. This is one place where I really think experience helps though.. after you've been doing this a few years assuming you ever go back and look at your old code it's inevitable you'll have the "wtf was I thinking?!?" moment. So eventually a good developer will get to the point where they are comfortable making the statement..

"This code is great but it probably has some room for improvement."

It's at this point that a good developer will arm themselves with various tools.. unit testing (and hopefully some coverage testing) being the most prominent. Which isn't to say that unit testing, coverage testing is going to catch every bug. These tools are good at finding code quality and logic problems with code but they miss out on many other types of errors. Igloo Coder mentions using Q&A to help find your issues and this is going to help you catch substantionally more errors. One thing I would add to this is that it's a good idea to have someone in your Q&A team who is either a domain expert on the problem the application was created to solve or even better is one of your clients. You'd be amazed how many clients you have that WANT to help.. that if you talk to about testing code (and explain that there are going to be some quality issues) will gladly take your latest iteration (after your technical Q&A people have gone over it) and work through it. This kind of person can bring you valuable insight into what your application does great and what it does poor.

Of course you will need to remember that like all people this person has a personal agenda. They want to help you resolve issues with the application but they also want it to work how they think things should work. So you need to balance the feedback from them with what you know about the application. And when something they are recommending goes completely against your understanding of what should be you may want to consider talking to other clients. Verify what the general expectation is. Sometimes your original understanding will be bang on.. and other times you'll wonder how the requirements you have are so far off them mark.

So assuming it's an option for you consider adding client involvement to your testing arsenal. Your application will be the better for it.

Thursday, October 12, 2006

NCover & NCoverExplorer Update

Thanks to a bit of help from Kiwidude I was able to use NCoverExplorer to get NCover working. It's a very cool tool that allows you to easily run NCover. It has a very nice interface that makes it easy as pie to run NCover against NUnit. Oh and it will even generate MSBuild and NAnt scripts for you. How cool is that?

So now that NCover has been added to my toolbox I'm wondering how best to integrate it into the build process. Does anyone know if you can set it up so that if you don't have say 90% code coverage the build fails? Oh well something to investigate.

Next on the list is a bit of special time with NDepend which is a code metrics tool. Should be fun.

Wednesday, October 11, 2006

It's all about what you've got in your toolbox...

Here is a quick list of what I've actually been playing with over the last few weeks and a bit of a comment on each.. I'll expand on each of these in an individual post when I've got a bit more brain power.

NUnit - This is an obvious one that most people should already know about. It brings the concept of "Unit Testing" to those of us who aren't working at Google, Microsoft or ThoughtWorks. This free “unit testing framework” is the basis of almost everything else I've learnt because without "Unit Testing" or that eventual goal of TDD the other tools don't make as much sense. NUnit was very easy to pickup thanks to the documentation that's available. It's also been nicely integrated into the other tools.

TestDriven.Net – This is an add-on for Visual Studio that allows you to run your NUnit (or various other unit testing frameworks) tests easily from within Visual Studio. The NUnit GUI is very cool but at the end of the day once you get past the cool green/yellow/red you’ll just want to know if you passed or failed as quickly as possible.

FxCop - I don't know about you but it feels like it has been a few years since I last tried FxCop. Back then I tried it.. looked at the giant list of issues (most of which appeared to be a bit silly) and promptly uninstalled it. Well if you're like me and you've grown up a bit it may be time to re-evaluate this little tool. I don't know if it's me or FxCop but the issues it finds seem to be a bit more important now and it wasn't actually that painful to get my project FxCop compliant. O

--- Intermission ---

So your world has started to brighten a bit.. you've got some unit tests written and your project was FxCop compliant last time you checked.. but if you’re like me you've got 50 things to do and trying to remember to run your unit tests all the time has fallen to the wayside. Which of course means that your unit tests are out of date and your code is not even close to FxCop compliant anymore. So does that mean you should give up on this whole unit testing concept? Go back to the way things were? Well No.. it just means you like me need a bit more process and thankfully the tools exist today to bring you that process.

And if you’re not like me and things have been humming along great.. Well maybe these tools will help them hum along just a little bit nicer.

--- End Intermission ---

CruiseControl.Net – If you a tree falls in the forest does anyone know? Well if that tree was being monitored by CruiseControl.Tree they would. CruiseControl.Net allows for “Continuous Integration” or as I like to call it.. knowing to nearly the second that your shit is broken. The concept is simple… every time code is checked into your source code repository (you are using one right? This is your lively hood we’re talking about isn’t it?) CruiseControl.Net will find out and then the magic begins. Using CC.Net with a little help from NAnt (explained below) your code is compiled, and optionally NUnit and FxCop are both ran. If any problem occurs you are notified either via email or via the little CC.Net system tray utility. Either way you can yell at the numbskull that just broke the code (or quickly fix it before someone else realizes that you’re the numbskull that broke it)

NAnt – Personally I started using NAnt for two reasons. The first being that it was the only way I could get CC.Net to build my application but more importantly I needed to be able to do a complete build, unit test, fxcop cycle with a single button click. NAnt is a tool that lets you build scripts to carry out various tasks. The fun thing is that while NAnt comes with many tasks there is also a community effort around building new tasks. So if you’re stuck using VSS as your source control (better than nothing.. worse than anything else) and you notice that NAnt doesn’t contain a task to retrieve your source code then NAntContrib will come to the rescue. Then it’s just a matter of putting together a build file (easy as pie using all the help available online) and you’ve got yourself a build process.

NCover – I haven’t actually gotten this to work.. mainly because the help sucks and there isn’t a lot in the blog sphere on how to set it up. Once I figure it out I’ll do a HOWTO. Oh and it appears that there are two seperate NCover projects. I'm using the NCover.org one.

ReSharper – If you are a C# developer and you are not using this tool.. download it ASAP.. print out the default key map and get ready to stop using your mouse for so much.

I think at the end of the day all these tools are really about one thing. Process.. or as I like to call it "Forcing me to actually have a process". Each tool adds a bit to your individual or team process and once you have them all in place and see them actually help your development efforts you can't imagine how you got by without them.

Learning... or the day I remembered I like being a Software Developer...

Long story short not to long ago I was considering not being a software developer anymore.. good news for me and my sanity I switched to a new company and got a new lease on the good or is that geek? life :) Add a little Edmonton .Net User Group and some Jean-Paul into the mix and suddenly I realize how much I've missed and how little time I've spent learning over the last 3 years.

With that in mind I've spent the last few weeks trying to cram those missed 3 years into a few weeks. Of course that's impossible but I do have the basics down in quite a few things and am learning more everday. With that in mind I'll be doing a few posts on various technologies from the point of view of a complete newbie and my thoughts on it.

And if you yourself find that maybe you don't quite feel that same loving feeling for software development that you use to.. ask yourself one simple question.. When is the last time you saw or learnt something that made you get pumped up? If it's been awhile I'd recommend looking into a local .Net group, attend some information sessions by a seasoned pro or two or heck maybe just pick up a new book. You may find that it's not software development that's gotten stale.. but lack of learning.

Shane

Jean-Paul Podcast

Well Jean-Paul has delivered another excellent performance, this time via a podcast on Developer Night in Canada. In it he starts with a discussion on design patterns with a tangent or two into the world of TDD and other topics of interest to developers of all shapes and sizes.

My only question is where is this guy's MVP? Oh wait it's probably waiting on the reference application we are all eagerly awaiting :)