A Code Sample is worth Ten References

Stack Overflow recently announced that they will start linking a user’s Careers account to their GitHub account. As the reason for this addition, they quote John Resig, the founder of JQuery:

When it comes to hiring, I’ll take a Github commit log over a resume any day.

I have to agree with him, and I’ll go even further: a code sample (commit log) is worth ten references.  The great thing about GitHub is that it’s a giant code-sample. Any developer on the internet can download your code, inspect it, and find the good and the bad instantaneously. Not only that, but they can view how often you commit, where your code has grown, and your interactions with the wider community as a whole.  That makes Github the perfect companion to your Stack Overflow profile (You have one of those, right? RIGHT?)

References, on the other hand, can be bought with a beer and good networking. I’ve had people come with references galore, but they couldn’t even code Fizzbuzz. I’ve never had a candidate with a good code sample turn into a bad employee. Github takes care of code sample problem writ large.

If you have a personal project and it isn’t a money-making venture, why not commit it to Github?

Caffeine

Image courtesy gamerevolution.com

Lent is a yearly Catholic Tradition that involves sacrifice, penance and generally a lot of guilt (When you’re Catholic, what *doesn’t* involve guilt?).  Last year, as Lent approached far more rapidly than I would have liked, I panicked because I had no idea what to ‘give up’ for Lent.  As Catholics, we generally ‘give something up’ that is near and dear to us, as a measure of sacrifice.  One year I gave up being nice; although in hindsight that wasn’t a very good idea.  

So for lent last year, I gave up caffeine.  That miracle drug that enables programmers to leap tall buildings in a single bound or to write reams of code in no time at all.  The same caffeine that is in just about every soda known to man. I gave it up.

I guess if you don’t consume caffeine at the rate I did, this isn’t a shock. It’s just caffeine.  It stops being ‘just caffeine’ when you consume upwards of 2 liters per day of the stuff. I’d have a soda in the morning, then a coffee, then another soda for lunch, then a soda and coffee in the mid afternoon.  I’d have soda with dinner and one or two sodas after dinner. My energy levels also fluctuated with the amount of caffeine I had. If I had caffeine in me, I was energetic, but the second it wore off I’d almost fall asleep (I drank sugar free soda, so it wasn’t a sugar crash).  Headaches were common when I went more than a few hours without caffeine, and I was generally irritable without it.

So I gave it up.

For the next 30 days, my life was a living hell.  Advil every 6 hours, lots of water, and irritableness as I came off of the caffeine.  After that, something strange happened: I was no longer tired at work, nor did I have a problem going to bed at night. I no longer got headaches, and my moods were mellower without caffeine.

A year later, I still don’t consume caffeine. If I feel the craving for a soda, I’ll buy a caffeine free diet drink (though there’s talk that even that’s ‘bad for you’); and at home I make Decaffeinated Iced-tea with Splenda.  If I have guests over, I’ll make them coffee (my mom would probably kill me if I didn’t have coffee for when she came to visit!), but otherwise I keep very little caffeine in the house.  At restaurants, where caffeinated sodas are the norm, I’ll either have water or a beer.

Caffeine changed my life: And being without caffeine has made my life immeasurably better. It may not be for everyone, but for me, it was worth it.

 

The First Step to Agile is Feedback

Implementing Agile in Microsoft Project

Image Courtesy: The Daily WTF

A little over a year ago I became the team lead for a software team in a company that specialized in government contracting, and in particular the US Army.  The company had been awarded “CMMI Level 3” compliance, and that was good enough for the government; but unfortunately CMMI doesn’t mean good software. It just means a reliable process was involved, even if it’s a crappy process.

Before I took over as Dev lead, our development cycles were 3 months from prioritization to delivery, with the product being a .NET 2.0 Winforms client.  We spent a lot of time responding to customer requests (aka putting out fires), and when we weren’t doing that, we were planning. Lots and lots of planning.  Planning is almost a pastime in government contracting.  The planning also fails, consistently.  Plan for 3 months away and in a month we found out that everything we had planned for had changed. 

You probably know where this is heading.  I started to institute agile within my team. Our meetings had been weekly meetings that lasted two hours and included people from other teams who were not acting in a supervisory role but were supervising. They included minutes, and they included the on-site customer rep taking every little thing we talked about back to his hierarchy.  In short, they were useless.  Those meetings were the first to go; and in their place was the daily standup. 15 minutes, 3 questions and we were done. I built a virtual kanban board that pulled the data from our bug repository, and we used that to keep track of where everything was at for the release.  Having no formal agile experience, I didn’t know where else to go from there.  The rest of our organization (1 other dev team, plus a QA team and System Engineering team) were still under the previous constraints, and because of the pain of our release cycle, there was no way we’d release code faster than every 3 months… unless we changed the rules.

Change the rules I did. I found a way to be able to update the clients without new installs (Click Once was a no-go, due to customer ‘concerns about security’) in RemoteApp, and it also alleviated the load pain we were feeling (due to complex object graphs serializing using .NET Remoting).  So I started to push for this upgrade; knowing it would pave the way for us to be able to shorten our feedback loop from the time we found out about a problem until we were able to release a fix for it.  It also meant we’d be able to deploy features much faster and get feedback on them much faster.

In the meantime, the project suffered from the same problems it had before: poor communication through ‘official channels’,  feedback not being given or received in a timely fashion, and features the users didn’t want or need. In the end, we didn’t communicate enough to the customer about all of the ways to improve the software or the problems with the approach we chose. We failed to communicate, and we   For all my efforts, I failed to make the project better.

I failed because I didn’t put the feedback first.  Agile is first about feedback. It’s about that communication loop between the people that use the software and the people that create it.  Before the technology, before the kanban board, and before anything else, the communication has to be fixed first.

We didn’t have communication across teams: Our teams were silo’d so that only the QA lead would talk to QA guys, the Sys-Engineering lead to the System engineering guys, and the other Dev lead to his team. I even exhibited “Don’t fuck with my territory” behavior. We were scared, we were defensive, and we didn’t knock down the walls that keep that feedback loop from happening.

The easiest thing to do is to improve feedback. Improve feedback by cutting the planning the release cycle, improve feedback by mixing the teams. Improve feedback by shuffling management around, or abolish it completely. Get rid of anything that hinders actual honest-to-god communication. That includes punishing people when they do speak up. Punish people when they’re disrespectful, not when they’re vocal.

Looking back on the many failures in that project, feedback was the worst, and it was also the easiest to fix.

Agile fixes communication in multiple ways, the first is that it requires cross-functional teams. A team in the Agile world is made up of the customer, the developers, QA, the scrum master, and any other business representative that has a stake in the process.  Secondly, Agile mandates constant communication to the customer and to the rest of the team about the state of the project.  It improves feedback by limiting the scope of work to what can be delivered in two weeks.  The most a team can ever be behind what the end-user wants is two weeks, instead of the three months we were previously. It also does away with those fiefdoms that crop up in silo’d organizations.  It may not be the answer, but it is a better answer than the status quo.

Little Gems: ToShortDate Extension Method

I’m really surprised that the DateTime struct doesn’t have a way to compare if two dates are equal, disregarding the time.  To help that, I’ve created an extension method:

 


public static class DateTimeExtensions
{
	public static DateTime ToShortDate(this DateTime dateTime)
	{
		return new DateTime(dateTime.Year, dateTime.Month, dateTime.Day);
	}
}

 

With this you can compare dates without worrying about the time they were posted, which is useful when you want to group items into blocks of days.

Have a better way? Share it in the comments.

Update:  That didn’t take long. In the comments, Andy West points out that Stack Overflow has a question on this very subject: How do I compare dates in C#? Time for me to do some reverting.

Visiting Exception Handlers

Scott Hanselmen recently posted a blog post titled Good Exception Management Rule of Thumb, Back to Basics Edition

 


public void HandleException(String strMessage)
{
//Log to trace file only if app settings are true
if (Properties.Settings.Default.TraceLogging == true)
{
try
{
TraceSource objTrace = new TraceSource("YadaYadaTraceSource");
objTrace.TraceEvent(TraceEventType.Information, 5, strMessage.ToUpper());
objTrace.Flush();
objTrace.Close();
}
catch
{
//do nothing if there was an error
}
}
throw new Exception(Environment.NewLine + strMessage);
}

The block is supposed to be the final stop for any and all exceptions in an application; if no other block of code handles it, this one will.  Scott asked his blog readers to post their thoughts in the comments, and I thought I’d do one better, and post my thoughts here.

Parameter and Method

 

  • Method: Why isn’t it static?
  • Parameter Name.  Faux-Hungarian notation blows.  It’s a statically typed language, so we already know that we’re expecting a string. 
  • Message? We pass messages in OO world. It’s just what we do.  What sort of message is it? (Hint: It’s an exception)
  • The parameter that comes in should be of type Exception, not string.
Conditional Logic
  • Explicitly checking for true is superfluous in the if statement.  If TraceLogging is a boolean property, then the entire equals and everything to the right can be taken out.
  • Why does the comment tell me exactly what the conditional logic tells me?
Try/Catch
  • The Try catch block shouldn’t be there.  If there’s nothing in the catch, then it’s going to catch everything and swallow it if anything goes wrong. Whoops, probably not what we wanted. It should be a try/finally block, with the Close() and Flush() happening on the finally block (the flush should happen first, then the close). I also believe that Close calls flush, so there’s no need to say flush then close. Just close will do.
  • Again, with the hungarian notation.  They made great ghoulash, but not so great programming prefixes.
  • Magic number: 5. What does 5 mean? I went to Kings Dominion with a few friends of mine last summer.  One of my friends was deathly scared of roller coasters, so I took it as a personal challenge to get her on a roller coaster.  We happened upon the Flight of Fear, an indoor coaster that you can’t see until you’re actually on the ride.  As we were waiting in line, she noted the sign that showed a Double-Diamond with a 5 in front of it.  She looked at me and asked 5 was the worst.  I replied that it was a 5 out of 10.  My point is, context means everything.  An enum to replace the 5 would be preferable. Since this is System.Diagnostics.Trace we’re talking about, 5 is the event Identifier.  Again, an enum would make it much simpler for maintanence programmers to remember what’s what.
  • What’s with the ToUpper()? Do you want your users to have a heart attack, or think that you’re yelling at them? HOW DOES THIS COME ACROSS?  Kill the ToUpper(), you’ll save yourself money.
Throwing Exceptions
  • When you throw new exceptions, you lose the Stack Trace coming up to that point, definitely not what the poster wanted, I’m sure.  
So now that we have the pain points with the original code down, let’s update it:

public static void HandleException(Exception ex)
{
if (Properties.Settings.Default.TraceLoggingEnabled)
{
try
{
TraceSource trace = new TraceSource("YadaYadaTraceSource");
trace.TraceEvent(TraceEventType.Information, Trace.ApplicationException, ex.Message);

}
finally
{
trace.Flush();
trace.Close();
}
}
throw;
}

 What do you think, is the new way better? I look forward to your comments.