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.

Blenders

A few years ago, during my quest to lose weight, I started using blenders to make a morning protein shake.  I didn’t know a lot about blenders, so I picked a target special. The blender worked well at first, and until I started it using daily, I never had any problems with it.  But boy did that change.  First, blending ice in a blender is hard to get right when making a smoothie: If you blend too much ice, you risk the blender slowing down to a crawl and overheating. Second, a target blender doesn’t blend all the ice uniformly, and not everything sinks back to the bottom, causing uneven blends.  Third, since the base of the blender is so small, there’s no circulating motion, so the entire blending process is filled with shaking and repositioning the blender.

Without Which Not

rythmn Interactive Score on Joel Test

I’ve written a few times about the Joel Test.  Most of the time it’s lamenting how businesses don’t score well on the Joel test. Other times, it’s extending the Joel test with my own requirements as a programmer.  I’ve never stressed how vitally important the Joel test is.  So important, that parts of it shouldn’t even be optional.  They should be Sina qua non, those essential elements that make programming, programming.  The other parts can be forgotten — at first, but if you ever want your business to be truly ‘best of breed’ (whatever that means), then you’re going to need to all 12.

Source Control: This is essential. It doesn’t matter if you have 1 programmer who is little more than a college student in a basement.  Get him source control, immediately.  Source Control is the programmer’s version of backing up important documents.  As a business person, most of your business plan is in your head.  Imagine if every part of your business existed only on paper, and that paper was stored in your house.  Now also imagine that you have a 13% chance of losing your house to a fire this year.   Wouldn’t you want those documents backed up? Get Subversion. It’s free.  Once you get used to having source control, then we can start fighting about which one to use.

Rythmn Interactive Job PostingBug Database: You have to have somewhere to record the issues you’re having with the software.  I’m a pretty smart guy, but I can’t remember what I did last week.  Now, ask me to remember the 300 things that need done over the next year? Forget about it.  Write it down.  It doesn’t matter if it’s an excel spreadsheet or a free copy of Bugzilla.  Write it down.

Best Tools Money Can Buy: Simply put: Do you invest in your programmers?  You invest in your product every year. Your profit goes directly to making the product better.  If I told you that by investing in your programmers you could increase the quality of your product, would you believe me?  It’s true. You never hear of a great programmer working at a mediocre company.  What do you think draws a great programmer to your company? It’s your investment in him, stupid.

Essential Tools for a programmer:

Do you have a spec? & Do you have a Schedule?: Do you have a roadmap where you want your business to be in 5 years? You probably do. If not, you at least have a roadmap for this year.  If you’re reading this, then clearly you have some sort of software solution in mind. So why the hell don’t you have a roadmap for your software?  Does that Roadmap tell you what needs to be done? A specification isn’t just a plan for a feature; it’s a plan for your software. Before you can build the feature, you need to know what your software is going to do. And programmers, being the anal retentive beings we are, are going to develop according to that spec.  If we don’t know what you want us to build, we can’t build it.

Do you have testers? I don’t care if it’s your ex-roommate’s girlfriend. Someone other than the programmers needs to put that software through its paces before it goes out to your customer.  It’s a dirty little secret, but we suck at testing our own software.  The software I write passes my tests every time, making me the worst judge of its abilities. 

Sina Qua Non is a latin term that means literally, “Without Which Not”, necessary preconditions for something to exist.  Without those five things, it isn’t programming; it’s an accident waiting to happen.

Bonus:

@LizardBill states: Totally agree. I’d rather sit in a cube with source control than an office without it.

Programmers.stackexchange.com has a question on the subject, “What is the bare minimum on the Joel Test?”, to which my answer is… well, you know my answer.