Recently I was cleaning up some code in a legacy application and found this little gem:

private IList entities = new List

Ouch.

This code was written about 2005. C# had the 'using' block, as well as try/catch/finally.  But in this case, neither is used to clean up the dataAdapter .

That's important to know. It's really easy for me to cast judgement on this code; but what really matters is *why* this code was written the way it was.  It's not as if the people that worked on this application were stupid -- on the contrary they were probably quite smart.  There are a number of reasons why it was written this way:

1. Programmer didn't understand what could happen to the open connection if something failed.
2. Programmer didn't realize there was a 'using' or 'finally' statement in C#.
3. Time.
4. No Code reviews (or)
5. No one senior enough to review the code.

There's a certain amount of 'If it isn't broke, don't fix it' in legacy applications.  There's inertia against changing code, especially if the code physically works.  But the real question is, Should the code be changed? and the answer is unequivically Yes.

What happens if it bombs when calling FillSchema? What about if the connection to the database dies? What about if it throws an exception for some other reason? 

These are all questions we should be asking ourselves when working on code.  I hate to invoke Murphy, but if there's a chance that something can go wrong, it will. It's our job to make sure that when it does go wrong, we handle it gracefully.

Don't ever accept We've always done it that way as a valid reason to keep code the way it is. Code is a living document, not the Constitution. Treat it as such.

During the latter part of Basic Training, when the Drill Sergeants stopped screwing with us at every conceivable opportunity, they sat down and talked to us.  During one talk, a trainee (we weren't allowed to be called 'soldiers' yet) asked for tips on how to get promoted and on how to 'get ahead'.  

I wasn't prepared for what the Drill Sergeant said next.

The key to being promoted in the Army is simple: Follow through.  

Most soldiers don't worry about perfecting the fundamentals: Shining Boots, learning their Common Tasks, or any of those other things that make a soldier a look like a soldier.  After a soldier graduates from Initial Entry Training (Basic Training + MOS (Job) Training), they are assigned to a unit.  At that point, whatever discipline they have is a combination of their supervisor's dedication and their own.  As the Drill Sergeant pointed out to us, it's that personal dedication to completing a task that separates the 'ok' soldiers from the really good ones.  The soldiers that shine their boots, keep their uniforms pressed, and look the part end up getting promoted faster in the Army.

The same holds true in Software Development.  Very little of our job is actually coding.  Most of what we do is spread among various non-coding responsibilities: Managing User expectations, taking responsibility for software failures, collaborating with the users, other development teams, and the QA team.  Most software developers are great at being programmers.  But when it comes to explaining things in a way a user can understand, we don't fare so well.  It's bad enough that almost every job posting for a developer includes:

Exceptional verbal and written communication skills. You will need to be able to communicate complex technical concepts to the US and offshore development team, and communicate status, issues, and risks to our leadership team.

We're so bad at it (collectively) that an entire industry has been spawned to bridge the gap between software developers and business users.  You may remember this clip from Office Space:

In a recession, and with the smartest minds believing this is going to turn into a depression, it's time to move out of our comfort zone and follow through with the non-coding parts of our profession.  We don't have the luxury of avoiding human contact any longer. If you want to be a successful (and employed) programmer, you must learn to follow through.  Without that follow through, you may find yourself unemployed or worse, unmarketable.

Twitter is a neat little tool. I like it. I use it as a micro-blogging service, and it gives me a chance to get an up-to-the-minute fix on technology and programming. For instance, in the last week these are some of the items I've found on Twitter:

• 0-255 http://0to255.com/ (A resource for front-end web developers)
• XML is bad for you (http://www.windley.com/archives/2002/07/12.shtml)
• David Hasslehoff (The Hoff) hosted WWE Monday night
• Breaking changes in ASP.NET 4: http://www.hanselman.com/blog/ASPNET4BreakingChangesAndStuffToBeAwareOf.aspx
• Designing for the IPad: http://www.8164.org/designing-for-the-ipad/
• Designing for the IPad Reality Check: http://informationarchitects.jp/designing-for-ipad-reality-check/
• Drawing parent / child relationships using T-SQL: http://bradsruminations.blogspot.com/2010/04/t-sql-tuesday-005-reporting.html

I grew up in a transition period. A period that children didn't wear bicycle helmets, we played in creeks, woods, and other 'unsafe' areas, and apart from bumps and bruises, we ended up just fine. Then something happened. Parents stopped letting children play outside, children wore more padding than a football player to 'play dates', and everyone suddenly got more paranoid about safety.  Not surprisingly, people still get hurt, maybe even moreso. So it's a surprise to learn that there is an experiment in place to go in the other direction:

For a number of years now, a number of cities in Europe have been experimenting with the removal of all traffic signs – including traffic lights, stop signs, speed limit directives – and with surprising results. Various towns in the Netherlands, Germany, Belgium, Sweden, New Zealand – even the UK! – have joined in the experiment. Contrary to the expectations of those who might expect multi-car pileups throughout the cities, traffic accidents have been dramatically reduced (in one town, dropping from about eight per year to fewer than two).

The architect of this experiment, the late Hans Monderman, is quoted to have said, "it is dangerous, which is exactly what we want":

"Unsafe is safe" was the title of a conference held on this practice. Monderman added that this effort "shifts the emphasis away from the Government taking the risk, to the driver being responsible for his or her own risk." Equally significant, drivers now focus more of their attention on other motorists – taking visual cues from one another, informally negotiating for space, turning into an intersection, etc. – instead of mechanistically responding to signs and electronic machines.

Monderman stated: "When you don’t know exactly who has right of way, you tend to seek eye contact with other road users. You automatically reduce your speed, you have contact with other people and you take greater care." He added: "The many rules strip us of the most important thing: the ability to be considerate. We’re losing our capacity for socially responsible behavior." In words so applicable to the rest of our politically-structured lives, he declared: "The greater the number of prescriptions, the more people’s sense of personal responsibility dwindles." Monderman expressed the matter more succinctly in saying: "When you treat people like idiots, they’ll behave like idiots." (emphasis mine)

It boils down to this: If you want people to act in a safe manner, remove the safety factor.

For software developers, we've heard it in the religious wars between managed languages and unmanaged languages, and in the erroneous assumption that managed languages do not have memory leaks. I don't have any solutions, although I believe the answer leans towards 'Unsafe is safe'. Take away the illusion of a safety net and programmers (and people in general) will start paying more attention to their work. You won't have any C# 'Slap this together' apps, but is that really a bad thing?

Bonus: Cracked.com has an article out today on 6 Scientific Reasons People Drive Like A-Holes. Check out reason #4.

Captain's log, Stardate 43539.1. We have moved into orbit around Bre'el IV. With the assistance of the planet's emergency control center, we are investigating a catastrophic threat to the population from a descending asteroidal moon."
"Captain's log, supplemental. We are no closer to finding a solution to the deteriorating orbit of the Bre'el moon, but with the arrival of Q we now have a good idea of the cause."
"Captain's log, supplemental. We have sustained light damage from an attack by an alien species known as the Calamarain. They apparently have a grievance with Q – no doubt one of many lifeforms that do." (TNG: "Deja Q")

The Captain's Log takes you through the high notes, letting you know three things:

1. What happened
2. What's happening now

Or this:

Captains Log, Stardate 51734.1 "Wesley crusher came onto the ship today and proceeded to shut down life support and jettison the warp core. There's no way to leave the ship."

The first one, of course. It sounds better. it's more complete, and in case your ship is found adrift with all crew dead, at least someone has an inkling of what happened to you.

Just like in code.

You fix a problem, you go on vacation or win the lottery, or quit.  As soon as you step off the plane in Tahiti, there will be a bug with what you fixed.  The programmer tasked to fix this bug is going to want to know what you did. He has source control for that; but he's also going to need to know *why* you did what you did. What alternatives did you consider? 

I've written about this before.  

The bug report is your chance to concisely list the relevant issues with a bug, how you are going about fixing it, and most importantly, what didn't work.  Maybe I'm senile, but I can't remember what I fixed 6 days ago, let alone 6 weeks ago. The bug report helps me keep a running log of what I've tried and what I haven't.  In instances where it doesn't make sense to put it into a defect tracking system, I keep a personal notebook. It goes with me everywhere, and it contains details on any solution I've ever tried. It's my own personal Captain's Log, and privately I call it that.

If you're just publishing Changeset numbers and the word fixed in bug reports, you're doing your teammates a disservice. Programming is hard enough as it is, don't make it any harder by not 'showing your work'.

Congratulations! You were just given a new Programmer!

Pop Quiz:

Do you...

1. outfit your programmer with the standard office equipment?
2. order custom equipment specialized for software developers? 
3. ask your programmer what he needs to get his job done? 

 If you answered (2) or (3), you're on the right track. otherwise, you get a nice little tombstone when your developers leave, a la Oregon Trail:

Software developers do three things:

1. Concentrate really hard. 
2. Type a lot. 
3. Sit on their fourth point of contact for extended periods of time. 

How does the standard office equipment fare against these requirements?

Poorly. At best.

The monitor is a 15 inch LCD as one screen, and a laptop screen as the second. With any luck it's a desktop with two monitors, but sadly they're both 15 inches.

In some unspeakable instances developers have *one* monitor.  Prolific developers and bloggers have already beat this subject to death. To save you time, here's the right answer: High Quality monitors. At least two of them. Really big ones. Like 24"-30". 

Back to my flattened rear end. Office Chairs are expensive, no doubt.  Office chairs that meet our needs? Even more so. I bought a Herman Miller Mirra chair a while back based on recommendations from people I trust, and it's the best decision I ever made. Believe me when I say that I'm halfway tempted to take it with me to work:

The final piece of the puzzle is a really fast computer.  Really fast. Not "Oh, I bought this from Dell" fast, but "We needed to custom order these" fast. 

I could spend and entire blog post on that alone (and probably will), but here's a good rule of thumb: If you can buy it without having to customize it, it's wrong. Your action word to the Sales rep should be 'More'.

Overall, this will cost about $4000 a developer. Another 2-3 grand for the PC.  In return, you get a developer who is happier, more productive, and is less likely to jump ship when one of your competitors wises up and starts offering these perks.

Don't think about it as a cost, think about it as a savings: For any developer you lose, you're going to lose a lot more than $4000 to replace them.

I enjoy reading about interviews. Especially the bad ones.  Luckily The Daily WTF keeps me stocked with stories that would chill your bones:

A Doomed Interview (from John) 
Times have been tough, so I've been looking just about evernwhere for work. Buried in the last page of the local newspaper, I found a tiny job ad seeking a candidate with several technologies I had experience with. Against my better judgment, I called the number and, after a few minutes of small talk, was invited to an interview. Not the next day, not the next week, but right then and there. Within hours, I found myself on a backwater industrial parkway, standing in front of a non-descript building.

Stepping through the front door was like entering a DooM level: dark as hell, a creepy bad atmosphere, and a slight fear that a giant spider was lurking around the corner. As my eyes adjusted to the gloom, it took all of three seconds to realize that I didn't want to work there. Against my better judgment, I headed in and up a dimly lit staircase.

The office was decrepit, devoid of people, and looked like a dingy basement with clutter, files, and junk strewn everywhere.What kind of a person would work here, I asked myself. Against my better judgment, I tapped on the door and called out "Hello?". 

You'll just have to visit The Daily WTF to see how it ends, for my part; I've only had one really weird interviewing experience:

The year was 2007, the bubble was bursting but no one in the banking industry realized it yet; especially not the two floor trading specialists that needed a software developer who could troubleshoot application problems on the 'trading floor'. I sent in my resume and was called for an interview.  At the time Wachovia was building a skyscraper in Charlotte; it was the topic of conversation by every recruiter or interviewer I talked to that day.  Except for one fateful conversation.

Two of the members of the application development team started taking me through the interview process, and let me know that they were going to stress me out while requiring me to solve brain teasers on a whiteboard. Somewhat confused, I replied, "You know I was in the Army, right?"  I guess that didn't meet their definition of stress. They continued to ask me rather hurried questions about various programming ideas while wondering why I hadn't solved their problem about the snail going up the well wall. 

Fast forward six months, and their division was cut (due to the recession), and my job would have undergone a cut as well. Their skyscraper is now owned by Duke, and they were bought out by Wells Fargo. I went on to a contract as a Web Application Developer using Perl.

Same Shiny Boots

In the Army, I spent hours shining my boots. On days where I wore my dress uniform (very few), every part of my uniform looked amazing. If I didn't have the time to shine my boots, I took them to a retired Sergeant Major that made a living shining other peoples' boots.

My obsessive behavior over my uniform is the only thing that differentiated me from other soldiers.  We were all the same; same haircut, same uniform, same shiny boots. 

Many soldiers complained about shining boots or having to prepare their uniforms, but we all understood the reason behind it. If you didn't have the discipline in your daily life, you wouldn't have that discipline when other people depended on you in combat.

Behold, the Tie

When I left the Army, I worked at a variety of places; some with a flip-flop and T-shirt dress code, and others that required 'Business Casual'. None of them ever broached the line that required developers to wear a tie.

Ties are a long standing symbol of professionalism in the civilian world. If you are wearing 'Business Professional' attire, people take you more seriously and think you know what you're doing (newsflash: All of Wall street wears ties).  They're more likely to trust you, and if you're especially smart about your attire, it can be the difference in choosing who to promote. There's even an unwritten rule: Dress for the position you want, not the one you have. 

None of which applies to software development.

Shaken, not Stirred

It's because software development is 1 part common sense, 1 part counter-culture, and 1 part fledgling industry. 

If you aren't interacting with a client, wearing a Tie doesn't make sense. It is doubly so when your job depends so much on getting into a mental groove; a groove that's much harder to attain if you're constantly thinking about the lack of blood flow to your brain.  There's also the time aspect. If I'm spending an hour a night worrying about my attire for the next day (I'm colorblind, give me a break), then that's an hour I'm not spending researching Windows Communication Foundation, playing with Ruby, or helping out on Stack Overflow. All of these make me more valuable to my employer. Wearing a tie does not. 

There's also the talent cost. If you have a great developer that can choose his company, all else being equal, he will choose the company without the tie. 

Third, our industry is young, and its roots are predicated on rebellion against the status-quo. 

Tie it up

If you don't have face-to-face time with a customer, you shouldn't be scruffy looking, but a tie isn't necessary either. If you're a business owner, your programmers will be more productive, happier, and more likely to stay around if you relax your dress code.  Think about it, it's cheaper than a raise.

I like Target. That probably has as much to do with a lack of alternatives as it does their appeal. Normally I'd go to Wal-mart. However, there are no Wal-mart stores in Northern Virginia. I think there's one, but it's rather sketchy. Coming from the south where Walmart is a local hangout, it's strange not to see one for miles. Not that I'd ever 'hang out' in one. But it happens, or so I'm told.

It is, as they say, what it is. I'm not really sure *what* it is though.

Back to the matter at hand.

Target uses a system of measurement to ensure that the cashier is speedily checking customers through the line.  This measuring device uses one criteria to measure a cashier's worth: How long it takes them to check a person out. From red-bar-of-doom to red-bar-of-doom.  there are two options "R" (for "Red" i guess), and "G" (which probably means "Green", which is a good thing. I think.) it looks like this:

88%
GGGGGGRRGG

What this says is that the employee has received '88%' green scores for his shift, and in the past ten transactions, has had two 'R' (Red, or "Bad") transactions. 

It says nothing about the accuracy of his work.

My fiancee and I were shopping at Target one evening and a cashier inadvertently gave us an item without ringing it up. It could have been because I was chatting with the cashier or it could have been because he was tired and just ready to go home and spend an hour figuring out Lost. Who knows. 

What good did Target's (probably expensive) measuring system do them? None.

That's the problem with measuring in general.  If you measure something, you incentivise it. Target measured the speed at which customers are checked out. That causes the cashiers to pay attention to how quickly it takes them to check customers out, which means they go faster. Pretty soon Target is starting to miss a non-trivial amount of merchandise that is neither caused by internal loss or by shoplifting. 

You're reading this post right now, and at least one of you is saying, "That's great, but I can't change that. I'm just a programmer." Bull. You aren't just a programmer, you create substance out of thin air.

 Business people know business -- but they don't have a monopoly on common sense. We deal with common sense every minute of the day (or lack thereof, depending upon our neighbor's code).  That's part of our value as programmers. Without that, we're just glorified code monkeys.

I've always wondered why rugby players seem to get injured less than Football players. It doesn't make sense to me. Football players have pads, Rugby players do not. One is protected, the other is not. One gets injured, the other does not. QED. 

So why in the name of Chuck Norris do Football players have more frequent and more extreme injuries than Rugby players?

The answer is in the pads:

[UMKC physics professor Robbert] Riggs believes there would be fewer serious injuries if players didn’t wear pads or helmets.

"As a retired Marine officer," Riggs said, "I know that when you’re wearing body armor, sometimes you feel invincible and I think there’s some of that. They put on all those pads and they feel invincible." (emphasis mine)

Sound familiar? (warning, PDF)

The developer does not need to explicitly free memory assigned to an object, which goes a long way toward reducing the amount of time spent debugging memory leaks. (10) There can be no memory leaks in 100% managed code.

Not only is this statement downright false, it's also dangerous.  

Google currently has 103,000 hits for "Memory Leak C#", and they all contain a similar tale of woe, programmers telling other programmers how not to make the same mistake they did. Each example boils down to one of three things:

1. Not de-referencing an event handler:

My most recent encounter with a memory leak was much like this: There was a class that dealt with dynamically wiring up events for other objects (as if they couldn't do it themselves?) and although these references went out of scope, the event handlers were still hanging around, subscribing to references that were now gone. Anything that was being used as a reference couldn't be garbage-collected, resulting in hundreds of megabytes of memory being retained over the course of an application's life.

2. Creating global references to objects:

I don't care what Greenpeace tells you: Think locally, not globally. Objects that don't have external references are much easier to keep track of than those that do. 

3. Disposing of Forms

If you're a Winforms or Webforms developer, this one is for you. ASP.NET MVC guys get a pass because they wised up. If you're using something that isn't yours, Dispose of it. Period. Database Handles, Filehandles, Controls, Forms, Whatever. Dispose of it. 

Bad decisions have a half-life that rivals uranium. Don't make bad decisions: Know your code.