Shane Courtrille's Blog

I'm going to be giving a talk on State & Interaction Based Testing in the very near future so as part of that effort I'd like to collect my thoughts and experiences on unit testing in general.  I think a good place to start is why I unit test at all.  And for this we need to go back into the past.  A past I think most of you probably have your own version of...

I have "fond" memories of back when I was a VB 6 programmer.  Like all programmers I sat around and wrote code.  And that was about it.  Occasionally I'd run my application to make sure things looked like they might be working but I was most definitely a programmer (as opposed to a Software Developer). 

And I hated it.  If I wasn't sitting around crossing my fingers and toes while in prayer that the application wouldn't crash during a big show & tell then instead I was rushing to fix a crash that HAD occurred during a big show & tell.  I hated the pile of crap I had created over the last 5 years that I couldn't change for fear of breaking things.  I knew I was capable of better (after all some of this code was 5 years old and hopefully I had learnt a thing or two in that time..) but every time I did improve something I usually broke something else.  I hated this whole programming thing so much that I really started to look into being an electrician.  Zapping myself daily with live current couldn't be any more painful then what I was going through on a daily basis.

So I figured that maybe a switch to a new .Net project was what I needed to turn my life around.  I figured why not?  One last try before I became Shane The Electrician.  So at this point I switched companies and started on a brand new C# project.  It was glorious.. for awhile.  By this point in my life I had enough experience to realize that my code was headed in the same direction the code I had written before was headed.  At this point the question in my head was which kind of electrician was I going to be? 

And then everything changed.. it was like magic.  I remember it clearly for it was the first time I saw JP Boodhoo weave code like a true craftsman.  I watched in amazement as he presented on "Test Driven Development & ASP.NET".  He was.. writing these things called tests?  And he was proving his code worked before he even ran it?  And then he would change things and run the tests again.  OMG a test broke and he knew exactly what was wrong because the test told him in a nice little message.  It was in a word... AMAZING.  And I realized at that moment what had been missing from my life all those years.

For me testing is a safety net.  A giant warm fuzzy blanket that when done properly holds you in its warm embrace and keeps you feeling warm and cozy as you make all those formerly scary changes to your code.  With testing in place I can look at a big nasty ugly piece of code that must have been written by an idiot (me.. yesterday) and feel safe in my ability to improve that code without breaking the entire application. 

Of course at this point you're in one of two places... Either you know exactly why I bolded "when done properly" or you are hear to learn why... For which you will need to wait till next time.

James Shore wrote a great post titled The Decline and Fall of Agile and I have to say that I agree with him 100%. 

In my experiences I've...

Helped convert a company to a more Agile approach.. but without firmly understanding it.

In this instance we turned out being very lucky because our implementation of Agile was working pretty good when I left.  A large part of this was because we had a great Customer Proxy, we were already the testers (Cross-functional team) and we were all seated together so communication was great as well.  At the end of the day we had the stuff that James points out is important.  I think it also helped that we were a small team.  If we saw a problem we made changes to fix it immediately.  I think at some point I'll have to sit down with some of the people I know who still work there and get their view of how Agile is working/not working now. 

Worked at various companies that were trying to be Agile.. but without firmly understanding it.

 In these instances things did not turn out well at all.  Q&A was a completely separate entity.  The Customer Proxy (on projects that had one) was a shared resource (this NEVER works).  Sometimes we've still been able to pull something Agile(ish) off which has still been better then the typical 'Get It Done' methodology but was still nowhere near Scrum.  Other times all hope has been abandoned and the project reverted to 'Get It Done' (and loses developers at a good rate).

Why Is It So?

I think the big problem is that Agile has gotten to the point where large corporations are using it.  These companies for the most part have not been Agile in 50+ years.  Getting changes put in place to support a proper Agile methodology is a huge battle that requires a proper Scrum Master but one isn't being brought in. 

My personal response to all this is two fold.  The first step is going to be to become a Scrum Master.  To fill in the gaps in my information on how Scrum is supposed to work.  The second step is to be more diligent in future contracts.  To ensure that if the company is trying to be Agile that they appear to have an understanding of what that really means.  If they don't then I'll see if I can help them come to an understanding as to value of being properly prepared vs the dangers of running in headstrong.  My time is too valuable to waste on another  Agile(ish) attempt.  I want to work with companies that want to succeed.

Agile is NOT easy.  You get what you put in.  It's time for us to start reminding people of this..