Looks like a busy end of the month for me.  I am going to try to attend the following events in the next two weeks:

Atlanta Geek Dinner

Shawn Wildermuth is hosting another Geek Dinner on the north side of town, at Pappadeaux’s in Alpharetta on October 23rd.  I’ve missed the last few, so I’m really looking forward to getting back in the mix on these.  I love Pappadeaux’s, but hate the fact it’s in Alpha-tucky.  Oh well.

Pappadeaux Seafood Kitchen
10795 Davis Dr.
Alpharetta,GA 30004
770-992-5566

Agile Atlanta

The Agile Atlanta User Group is deviating from their usual scheduled meeting of every 2nd Tuesday of the month for a special event on Monday, October 27th.  Jeff Sutherland, the co-creator of Scrum and one of the authors of the Agile Manifesto is presenting at Turner’s Techwood Campus location.  The topic is titled, “Hyperproductive Distributed Scrum Teams”.  This is an amazing opportunity to hear one of the true leaders in the Agile community speak.  Turner has very tight security, so they are asking anybody who wishes to attend sign up beforehand.  You will need to sign up and present a photo ID for admittance into the building.

Techwood Campus at Turner
(1015 Assembly Room)
1050 Techwood Drive N.W.
Atlanta, GA 30318

Atlanta ALT.Net

The Atlanta ALT.Net group is holding another meetup on Wednesday, October 29th at Thinking Man Tavern in Decatur.  The topic of this meeting is Continuous Integration.  Josh Gough has done a great job organizing these meetings, and I look forward to another interesting and lively discussion.

Thinking Man Tavern
537 W Howard Ave
Decatur, GA 30030

Saturday, October 18, 2008 6:30:00 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  Agile | alt.net | Programming | User Groups

During our daily standup the other day, one of the developers was complaining about the lack of commenting in a module that was written by a 3rd party consulting firm.  This got many frustrated nods from the other developers in the group, which in turn led to a discussion of comments overall in our code.  There seemed to be a general consensus among the group that the commenting in our code needed to be improved overall.

The reason I found it interesting (and by interesting I mean to me only) was the the timing of it all. 

I’ve been on a kick lately to read nothing but Agile books (instead of the usual books on specific languages or technologies).  The one currently occupying my bedside table is a book by Robert C. Martin (aka “Uncle Bob”) called Clean Code : An Handbook of Agile Software Craftsmanship. 

Literally only a day or two before this particular stand-up meeting, I had read the section on commenting in the book.  In fact, Uncle Bob’s views on the subject were so strong that he dedicated an entire chapter to it.  He argues that comments overall are a “necessary evil” and are only needed as a means “to compensate for our failure to express ourself in code.”  He hopes someday that languages evolve to DSLs that are self-documenting.

He reasons that comments are bad because Agile code changes over time.  Oftentimes, the comments don’t get maintained along with the code.  So the more code gets changed, the comments become further away from the current intent of that code.  In fact, he boldly states that comments lie (though not necessarily intentionally), and that inaccurate comments do more harm than no comments at all.  A bad comment is worse than no comment (maybe Uncle Bob was a lawyer in a former life?). 

Well, if that’s the case, why bother commenting at all?

He does give some examples of useful comments:

• Legal comments, such as copyright headers, author statements, or ownership rights
• Warning of consequences
• TODO comments, which can be caught in IDEs as warnings

On the other hand, he provides numerous examples of bad comments:

• Documenting a “hack”
• Comments that mirror the functionality and/or naming of the code piece it describes
• Poorly written comments, which can be harder to read than the code itself
• Journal comments that log each time the code is changed
• Noisy comments that provide no value (e.g. // ignore )
• Position markers (e.g. //////// Public Methods /////////////)
• Closing brace comments (e.g. // end while)
• Commented out refactored code (a personal pet peeve of mine)

I don’t know if I agree with the extremist approach of removing all comments from my code.  But I do agree that comments are often abused as a replacement for good code.  The rule of thumb I came away from the book is: if you feel the need to document a complex chunk of code with a comment, that is a sure-fire sign of a code smell.  Step back and look at the code from an maintenance perspective.  Is this code likely to change?  What are the odds the comments will change with it?  Is the comment articulating my intent well?  Have I named my variables/methods/classes intuitively?  Most importantly - can I refactor the code into a standalone method that can be named expressively?

Comments can be useful, but many times end up being the poor man’s excuse for lazy coding.  Don’t be that guy (or gal).  Strive to make your code readable without having to resort to comments.

Friday, October 17, 2008 8:54:34 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  Agile | Back To Basics | Programming

My friend Brad Anderson is putting together a meetup for the Metro Atlanta Erlang Users Group.  They are planning their initial meeting to be at The Brick Store Pub in downtown Decatur this Saturday (September 20th) at 7pm. 

Unfortunately, I am probably not going to be able to make it since it's my anniversary weekend, but if you are at all interested in Erlang (or functional languages of any sort), it should be a good time.  He told me people are coming from as far away as Raleigh just for this meetup.  And if you enjoy good beer (who doesn't???), it doesn't get much better than the Brick Store.

Thursday, September 18, 2008 10:08:02 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  Erlang | Programming

Every project ends up with one or even possibly many static helper classes.  If you program in Java, I'm willing to bet the house your project has a StringUtil class lurking around somewhere.  These classes are easily abused, but can serve a valid purpose, such as a factory class responsible for creating instances. 

If these classes contain only static methods (as they usually do), there is never any reason for them to to be instantiated.  However, in both Java and C#, it's easy to forget that if you do not explicitly declare a constructor, the compiler will generate a no-arg constructor by default.  The consequence is that the following code is valid:

StringUtil util = new StringUtil();

You've just allocated memory unnecessarily.  Plus, the garbage collector will now incur extra overhead since it will have to reclaim this memory even though it was never actually used.  All of the methods are static, so there is no reason to instantiate an individual object from this class. 

To avoid instantiations, make sure you declare a private no-arg constructor.  This will cause the compiler to throw an error any time the class is attempted to be instantiated.

public class StringUtil
{
    // constructor marked private since all methods are static
    private StringUtil() {}

    // bunch of static methods not shown
}

A side note - If you are using C# 3.0, I recommend using extension methods to enhance the behavior of existing classes rather than creating a something like a dedicated StringUtil class.  First of all, any class declaring extension methods has to be marked as static and cannot be instantiated.  And more importantly, it provides a much cleaner implementation to add those helper methods directly on the affected class.  The added bonus is that Visual Studio is smart enough to provide Intellisense for extension methods on targeted classes.

Sunday, June 22, 2008 9:35:25 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  Back To Basics | C# | Java | Programming

Inspired by a recent Hanselminutes podcast about getting back to basics, along with my experiences at my last client, I've decided to start a series of blog posts on fundamentals and best practices.  Ideally, I'd like to post about once a week on some aspect of programming that isn't necessarily tied to a particular technology or framework.  While these posts may contain code samples in a particular language, I'd like them to be applicable across platforms.

In this first post, I want to talk about the gravitation of junior programmers to books on particular technologies rather than books on fundamentals. 

Let's face it - programming books are nearing end-of-life status.  Don't get me wrong, I love reading programming books (I'm finishing up one right now and have two more in the queue).  But in this age of the internet and how quickly technologies change, coupled with our "gotta have it now" instant gratification society, it's next to impossible to publish a book that is relevant, accurate, timely, and interesting.  My hat is off to those people who can do so successfully.

Despite this fact, programming books are (for now) still quite popular.  It's certainly not from a lack of volume, both in the number of books available and in the length of the individual books.  A former colleague of mine recently bought an ASP.Net book that appeared to have decimated half the pacific northwest and was so heavy it probably could be considered a weapon.  It makes me wonder how a publisher thinks any modern developer can consume 1,500 page books on subjects that, let's be honest, aren't particularly enthralling. 

Now I love the fact that developers are so interested in learning that they continue to buy programming books despite the logic that says they'd be better off googling and reading blogs.  Here's my problem with developers who buy programming books ... the books I see on developers' bookshelves tend to be targeted at particular technologies (e.g. LINQ, WCF, Ajax, etc...) rather than general software engineering practices.  In particular, I'm talking about junior developers who probably need the fundamental books the most.

Here is a starting place for books that I feel form a solid foundation for a professional programmer:

I've said it many times, I'd be much more inclined to have a strong developer on my team who has no experience in a particular technology rather than a weak one who has been doing that technology for 5 years.  Once you grasp the fundamentals, you can pick up any technology and be productive much quicker.

Friday, June 13, 2008 8:16:01 PM (Eastern Standard Time, UTC-05:00)      Comments [0]  Books | Programming