“Being Agile” Means No Documentation, Right?

Ask most software professionals what Agile is and they’ll probably start talking about flexibility and delivering what the customer wants.  Some may even mention the word “iterations”.  But inevitably, they’ll say at some point that it means less or even no documentation.  After all, doesn’t creating, updating, and circulating painstakingly comprehensive documentation that everyone and their mother have officially signed off on go against the very core of Agile?  Of course it does!  But really, they’re missing the point!

Read The Agile Manifesto. (No, seriously - read it now. It’s short. I’ll wait.)  It’s essentially a list of values.  More specifically, it’s a right-side/left-side weighted list of values:  “Value this over that”. Many people seem to get the impression that this is really a “good vs. bad” list and that those values on the right side are evil and should essentially be tossed on the floor.  This leads to the conclusion that in order to be Agile we must throw away our fancy expensive tools, document as little as possible, and scoff at the idea of a project plan.  This conclusion is quite convenient because it essentially means “less work, more productivity!” (particularly in regards to the documentation and project planning).  I couldn’t disagree with this conclusion more.

My interpretation of the Manifesto targets “over” as the operative word.  It’s not just a list of right vs. wrong or good vs. bad.  It’s a list of priorities.  In other words, none of the concepts on the list should be removed from your development lifecycle – they are all important… just not equally important.  This is not a unique interpretation, in fact it says so right at the end of the manifesto!

So, the next time your team sits down to tackle that big new project, don’t make the first order of business to outlaw all meetings, documentation, and project plans.  Instead, collaborate with both your team and the business members involved (you do have business members sitting in the room, directly involved in the project planning, right?) and determine the bare minimum that will allow all of you to work and communicate in the best way possible.  This often means that you can pick and choose which parts of the Agile methodologies and process work for your particular project and end up with an amalgamation of Waterfall, Agile, XP, SCRUM and whatever other methodologies the members of your team have been exposed to (my favorite is “SCRUMerfall”).

The biggest implication of this is that there is no one way to implement Agile.  There is no checklist with which you can tick off boxes and confidently conclude that, “Yep, we’re Agile™!”  In fact, depending on your business and the members of your team, moving to Agile full-bore may actually be ill-advised.  Such a drastic change just ends up taking everyone out of their comfort zone which they inevitably fall back into by the end of the project.  This often results in frustration to the point that Agile is abandoned altogether because “we just need to ship something!”  Needless to say, this is far more devastating to a project.

Instead, I offer this approach: keep it simple and take it slow.  If your business members or customers are only involved at the beginning phases and nowhere to be seen until the project is delivered, invite them to your daily meetings; encourage them to keep up to speed on what’s going on on a daily basis and provide feedback.  If your current process is heavy on the documentation, try to reduce it as opposed to eliminating it outright.  If you need a “TPS Change Request” signed in triplicate with a 5-day “cooling off period” before a change is implemented, try a simple bug tracking system!  Tighten the feedback loop!

Finally, at the end of every “iteration” (whatever that means to you, as long as it’s relatively frequent), take as much time as you can spare (even if it’s an hour or so) and perform some kind of retrospective.  Learn from your mistakes.  Figure out what’s working for you and what’s not, then fix it.  Before you know it you’ve got a handful of iterations and/or projects under your belt and you sit down with your team to realize that, “Hey, this is working - we’re pretty Agile!” 

After all, Agile is a Zen state.  It’s a destination that you aim for, not force, and even if you never reach true “enlightenment” that doesn’t mean your team can’t be exponentially better off from merely taking the journey.

Presentation: Razor and the Art of Templating

Had a blast tonight giving a presentation on Razor to my hometown user group, NJDOTNET.  While I kind of regret how much focus we gave to MVC instead of Razor itself, I’m glad people are so eager to talk about and learn more about MVC.

If you’re looking for the RazorPad application that I showed and discussed, you can find it here:   http://razorpad.codeplex.com
Please feel free to comment publicly and/or privately – any and all feedback is welcome!  Or, if you’d like to help me code it, that’d be awesome, too – just let me know!

Razor and the Art of Templating from Jess Chadwick on Vimeo.

Presentation: Automated Unit Testing for Mere Mortals

Last weekend I had the immense pleasure of getting my unit testing presentation selected as one in the great Code Camp NYC lineup.  It was a great crowd and this is the first time I tried to record one of my talks.  I think it turned out alright!  I’ve embedded the low-quality version below.  If you prefer the high-def version, here it is:  Unit Testing for Mere Mortals (720p).  

Enjoy, and please feel free to let me know what you think!

Presentation: Leveraging Continuous Integration for Fun and Profit!

This evening I had another chance to speak in front of a great group of folks:  the members of my “hometown” NJDOTNET!  Everyone had a lot of great questions and overall I thought it was a lot of fun, and (as always) I look forward to the opportunity to speak to this group again.  I just hope everyone got a lot out of it – I look forward to hearing about how everyone goes back to work tomorrow morning and asks their team to start doing continuous integration! :)

For those of you who were interested in my source code, config files or slides, I’ve uploaded them to my secret Internet file lair.  Feel free to download them and check them out, as well as hit me up with any questions – I’d be glad to try to answer them!

If you don’t care to download the files, you can peruse the slide deck online:

Leveraging Continuous Integration For Fun And Profit!

View more presentations from jesschadwick.

NYC Code Camp 2010

I had a great time presenting on the ASP.NET MVC Framework at the really awesome NYC Code Camp 2010 event today.  For those who wanted to look through the code, here is a link to the code I showed (with “start” and “finish” versions) and check out the slide deck inline below:

Introduction To ASP.NET MVC

View more presentations from jesschadwick.

   As always, feel free to contact me if you have any questions or are interested in learning more!

What’s a “Unit Test”?

No, I’m not talking about these guys...

Generally speaking, writing any kind of code that exercises the code you've written is a good thing, but the term “unit test” carries with it a very focused and specific meaning. Listed below are what I consider the top-most important qualities of a “unit test”:

• Atomic

  
  A unit test should focus on validating one small piece (“unit”) of functionality. Generally, this will be a single behavior or business case that a class exhibits. Quite often, this focus may be as narrow as a single method in a class (sometimes even a specific condition in a single method!). In practice, this equates to short tests with only a few (preferably just one) deliberate and meaningful assertions (Assert.That([…])).

  Common Pitfalls & Code Smells
  • Dozens of lines of code in one test
  • More than 2-3 assertions, especially when they’re against multiple objects

• Repeatable

  
  A unit test should produce exactly the same result at any time on any environment, given that environment fulfills a known set of dependencies, e.g. the .NET Framework. Tests cannot rely on anything in the external environment that isn’t under your direct control. For instance, you should never have to worry about having network/Internet connectivity, access to a database, file system permissions, or even the time of day (think DateTime.Now). Failed unit tests should indicate a bug in the code and nothing else.

  Common Pitfalls & Code Smells
  • Tests pass on the first execution, yet some or all fail on subsequent executions (or vice-versa)
  • “NOTE: The XYZTest must be run prior to this or it will fail!”

• Isolated / Independent

  In a culmination of the first two qualities, a unit test should be completely isolated from any other system or test. That is to say, a unit test should not assume or depend upon any other test having been run or external system (e.g. database) having a specific state or producing some specific result. Additionally, a unit test should also not create or leave behind any artifacts that may trip up other tests. This is certainly not to say that unit tests cannot share methods or even whole classes between each other – in fact, that is encouraged. What this means is that a unit test should not assume some other test has run previously or will run subsequently; these dependencies should instead be represented as explicit function calls or contained in your test fixture’s SetUp and TearDown methods that run prior to and immediately following every single test.

  Common Pitfalls & Code Smells
  • Database access
  • Tests fail when your network or VPN connection is disabled
  • Tests fail when you have not run some kind of external script (other than perhaps an NAnt script to compile, of course)
  • Tests fail when configuration settings change or are not correct
  • Tests must be executed under specific permissions

• Fast

  Assuming all of the above conditions are met, all tests should be “fast” (i.e. fractions of a second). Regardless, it is still beneficial to explicitly state that all unit tests should execute practically instantaneously. After all, one of the main benefits of an automated test suite is the ability to get the near-instant feedback about the current quality of your code. As the time to run the test suite increases, the frequency with which you execute it decreases. This directly translates into a great amount of time between the introduction and discovery of bugs.

  Common Pitfalls & Code Smells
  • Individual tests take longer than a fraction of a second to run

If one were really clever, they might arrange the above into a cute little acronym like “FAIR”, but the order in which they appear above is very deliberate; it is the rough order of importance that I place on each quality.

Unit Tests vs. Integration Tests

Odds are that if you have written any automated tests recently, you probably violated one of the above guidelines… and probably for very good reason! What you have produced, my friend, is another very valuable form of automated test called an integration test. As opposed to a unit test - whose sole purpose is to validate the logic and/or functionality of a specific class or method – an integration test exists to validate the interaction (or “integration”, as it were) between two or more components. In other words, integration tests give the system a good work-out to make sure that all of the individual parts work together to achieve the desired result – a working application.

As such, integration tests are just as – if not more so – valuable in a business sense as unit tests. Their major drawbacks, however, are their slow speed and fragility. Not only does this mean that they will get executed less frequently than a unit test suite, but the rate of false-positives (or negatives… however you want to look at it) is much higher. When a unit test fails, it is a sure indication of a bug in the code. In contrast, when an integration tests fails it may mean a bug in the code, but could also very well have been caused by other issues in the testing environment such as a lost database connection or corrupt/unexpected test data. These false positives - though a useful indicator that something is wrong in the developer’s environment – usually just serve to slow down the development process by taking the developer’s focus away from writing working code. Assuming you strive to avoid these distractions whenever possible, the conclusion I come to is that you should therefore strive to rely on extensive test coverage via a solid unit test suite and supplement that coverage with an integration test suite and not vice-versa.

References

A great deal of the reason I even took it upon myself to write this blog post was because I couldn’t really find any good online articles or posts concerning “what makes a unit test”!   Below are a few of the great ones I found.  It may seem like I stole from some of them, but the ideas above really are my opinions…  they just happened to be widely shared. :)

• Qualities of a Good Unit Test:  Jeremy Miller (The Shade Tree Developer)
• Writing Great Unit Tests:  Best and Worst Practices:  Steve Sanderson

However, it seems at this point if you are very interested in learning more about this topic, books are your best bet.  Anything by the “usual suspects” (Fowler, Hunt, Thomas, Newkirk…) is a great bet, but here are a few I have read and loved:

• Pragmatic Unit Testing In C# with NUnit:  Andy Hunt, Dave Thomas, Matt Hargett
• Test Driven Development: By Example:  Kent Beck   (focuses on the mentality behind unit testing over implementation)

TFS Ain’t So Expensive Anymore

Those of you who scoffed at the enormous price tag on previous releases of Team Foundation Server will be happy to hear about “TFS Basic” - the new offering of TFS 2010 (or as Brian calls it, “TFS for SourceSafe users”  **shudder**).  Presumably, this new offering includes all of the functionality that small development shops will need to thrive on TFS, while still offering a sane upgrade path.

I haven’t been able to find exactly how much this new SKU is going to run you, but from what I’ve seen it will not be $0.00 (AKA: free).  As my very last post may tell you, I am a huge fan of the free & open source offerings out there, but – as my last post shows – making these disparate projects integration together can quite often mean a whole lot of time and energy.  Even with the astronomical price tag of previous versions, the out-of-the-box integration of Source Control, Continuous Integration, and Change Tracking has always been incredibly alluring to me.  And, for those who really desired it, it was probably worth the cost.  The exciting part of this announcement is that you can now get this powerful integration – sans advanced features – for a fraction of what the full TFS system used to cost…  and that is pretty damn cool if you ask me.

Will I make the switch from Subversion+CruiseControl+[whatever change tracking and planning tool I’m using]?  Will I solicit my employer to switch?  No.  It’s nice to know that if one of the components isn’t working out for us or we find something better, we can replace just that one component and leave the others in place.  Additionally - while the initial pain in getting these open source solutions wired together can be substantial - once the initial price of time and effort is paid, it rarely gets in the way again.  However, those are existing installations I’m referring to;  for new projects, I will most definitely be evaluating TFS Basic along with the others and I expect that the savings we’d realize in integration alone will be enough to make it a leading contender.

For those of you who have never had the pleasure of using Team Foundation Server, I strongly suggest you go grab these bits and try it out.  Sure, it’s got its downsides (as anyone who follows me on Twitter knows), but it is also one hell of a nice product and certainly worth checking out.  What’s more – with TFS Basic, you no longer need to be in a server environment – you can feel free to install it on your local development environment!  Go download and install the bits and come back here and let me know what you think!

Issue Tracking Integration with Subversion & TortoiseSVN

Many development shops have the requirement to associate any code changes to a backlog item or defect to help track the time and energy spent working against a particular featureset.  This need is so prevelant, that the awesome TortoiseSVN Windows Explorer Subversion extension actually has some special settings you can use to help make your life a little easier.

Generally when demoing something like this, I like to show the finished result and then jump back to the beginning and follow the whole process step-by-step, but I’m going to break stride with this post.  I’m just gonna do it.  Here it goes:

How do you associate a backlog item/bug/issue ID with a check-in?

Add the “bugtraq:message” property to the root folder of your repository, and set it to something like “Backlog ID: %BUGID%”.

Yep, that’s it.  I know - crazy, right?  Next time you go to check in, you’ll see something like this:

NOTE

For those of you who have never used Subversion properties, the easiest way to add one is to right-click on your Subversion folder, then select “TortoiseSVN > Properties” which will bring you to the dialog where you can add and edit your Subversion properties.  All of the features I discuss in this post are unlocked using these properties.

Then, after filling in a value for the Backlog ID and hitting OK to complete the check-in, you can visit the history logs and see that TortoiseSVN has oh-so-nicely inserted the Backlog ID into your checkin comment for you, like so:

 

Some of you might be thinking, “But hey – I could have just typed that myself!”  Yeah, sure – if you wanna waste a bunch of time typing the same thing in every comment, this probably won’t be of much help to you… but wait – there’s more!

Make that integration experience a little bit nicer

For those of you who were underwhelmed with the first section, let’s dive a little deeper and check out some of the other bug tracking properties that TortoiseSVN has made available to us that allow us to customize this behavior:

• bugtraq:url – now this is the stuff you’ve been waiting for!  If you set this property with a URL pattern containing the %BUGID% placeholder, TortoiseSVN will be nice enough to turn those nifty little messages into direct links to your issue tracking system!  Naturally, this link will be different for every issue tracking system, but assuming your system allows you link directly to an issue via it’s ID, this is a pretty sweet option.  Here’s an example: 
  By setting the bugtraq:url property to “http://myversioncontrol/issues/%BUGID%”, my previous history message (shown below) now contains a link directly into my issue tracking system!

• bugtraq:warnifnoissue – this awesome setting tells Tortoise to yell at the dev (shown to the right) if they haven’t provided an Issue #.  It’s purely a client-side setting and provides no server-side validation so it’s not going to force the users to associate an issue #, but it sure is a nice reminder. 
  Note:  If you really want to perform server-side validation, stay tuned – a post on that topic should be coming up soon!

 

• bugtraq:append – if you’re like me and want the backlog/issue ID right at the beginning of the message instead of the end, you can set the “bugtraq:append” property to “false” so it prepends the ID snippet to the beginning of the log message instead of appending it to the end (as is the default behavior shown earlier).
  

 

• bugtraq:label – if you go waaay back to the first screenshot in this post, you’ll see that the label for the Backlog ID input box had the awkward default value of “Bug-ID / Issue-Nr:”  This bugged the heck out of me, and I wanted to change it to match my message of “Backlog ID:”, and luckily the bugtraq:label property let’s you do just that!   I just set the value of bugtraq:label=Backlog ID:, and I was good to go!

Well, I hope you found these useful and that they help you in your quest to write better software.  As always, if you know of a better way to do this or have any comments, suggestions, or questions, please feel free to comment below.

Good luck, and happy coding!

On to the Next Set of Challenges!

You won’t see many of my blog entries get too personal, largely due to the fact that I am a relatively private person to start with, but also because this is supposed to be a technical blog.  That said, I wanted to break stride for one post and speak to the fact that I am leaving Infragistics and have now moved on to new challenges by deciding to start consulting.

It has been a great 3.5 years at Infragistics for me and I can not speak highly enough of my time there.  Never before have I worked in an environment so rich with knowledge, intensity, and passion.  It is an environment of productivity; it’s where teams of great minds and talented professionals join forces to produce amazing results, wasting no time in shipping amazing stuff.  It’s also fast-paced: a few of us had at one point discussed the concept of “Infragistics Time” joking that one or two days at IG would be the equivalent of up to a week anywhere else… and I’m not just talking deliverables.  To put it another way, I joined Infragistics as a Senior Web Developer, but after only one year in, I’d learned more and gained more experience than the entire rest of my career combined.

I didn’t do all this learning in a silo.  Reporting to the guy I would end up calling my mentor - Ambrose Little - was a crucial aspect of my development.  Until you’ve actually met him (and if you haven’t had the pleasure, the least you can do is follow him on Twitter!), it’s hard to describe just how awesome this guy is.  Crazy smart, level-headed, patient, and open-minded are just a few words that come to mind.  He guided both me and our group to continuously increasing levels of success… and he was really only doing it “part-time”, having another whole set of responsibilities above and beyond managing me and the website(s)!  It was also through this team that Ambrose led that I was able to foster deep personal and professional relationships with Todd Snyder and Ed Blankenship – two guys that I guarantee will continue to be two of my most valuable friends and colleagues for the rest of my professional (and personal!) life.

As an active supporter of the .NET community, Infragistics also introduced me to the amazing rewards of community involvement.  In a matter of months I had gone from never having attended a local user group meeting to becoming a presenter and eventually assuming leadership of or local group, NJDOTNET and later earning Microsoft’s MVP award!  This was all great fun, but I only recently realized just how deeply this involvement had affected me when my recent job search had me writing out my professional priorities and “community involvement” emerged as #1!  And, I owe all of this to Infragistics’ support, as well as trying to follow in the footsteps of both Ambrose and Jason Beres… which is not an easy thing to do!

I didn’t mean for this post to be a biography of my tenure at Infragistics, and as such I am focusing on those with whom I worked the longest and who had the deepest impact on my life. Unfortunately, that means leaving out the myriad other great folks that I was lucky enough to meet and work with.  So, I’m sorry that I am leaving so many of you out, but you know who you are and – even if I wasn’t able to mention you specifically – thank you for making my time at Infragistics a great one!  Farewell everyone – I’m sure I’ll see you all again sooner or later!

Shameless Plug:

So…  as you may have noticed, I opened up this post by mentioning that I decided to start consulting.  That means that if you’re looking for some help to knock out that next awesome project of yours, please feel free to contact me! 

If you’re interested, here’s a link to my resume in Word 2007 format.

Book Review: NHibernate in Action

Over a year ago I wrote about my NHibernate Lazy Loading Snafu and in that blog post it was pretty clear I was mostly clueless when it came to NHibernate.  Unfortunately, that hasn’t changed much in the past year, so I was incredibly eager to get my hands on the new Manning book, NHibernate in Action.  Believe me, it did not disappoint.

I’d argue that this book may be more appropriately naming something along the lines of “ORM in Action (with a focus on NHibernate)” because it is not only a bible for understanding and using NHibernate, but for ORM concepts in general!  The authors skillfully intertwine detailed and insightful discussion of general database, ORM, and enterprise development concepts with the nitty-gritty implementation details of NHibernate, all in an easy-to-read manner.  Beginning with a tour of many of the various ORM (and ORM-ish) solutions available to .NET developers and ending with a few chapters dedicated to discussing best practices of enterprise application development, this is a very well-rounded book that is easily digested by developers of pretty much any skill level.  I knew only high-level details about NHibernate and had a few mis-guided attempts at implementing it by myself prior to reading this book, but now I feel incredibly confident that I will be able to create plenty of NHibernate-driven applications with ease.  Another great benefit is the comfort I get from knowing that when I hit any more snafus in the future, it is obviously that this book will be there as a solid reference to help get me through.

The cons?  It'd be nice if the book discussed NHibernate 2 & .NET 3.x functionality (like LINQ-to-NHibernate), but I think those expectations are somewhat unrealistic. Because of its open source nature, NHibernate is a living organism with stark contrast to a published book. Due to this contrast, I am more interested in a text that can explain the fundamental concepts than an incredibly in-depth (and quickly obsolete!) explanation of the technical implementation of those concepts.

When it comes down to it, this is a great book that delivers on its promises and provides a comprehensive look at NHibernate in Action and how you can get it working for you.  I’m just gonna come right out and say it – this is the NHibernate Bible.