On Being Wrong

I sent the shortest email ever today:

Jeff,

You’re right.

All the best,

George Stocker

The details aren’t really important. What is important is that I meant every word. It’s really hard to send a geniune email that short.  When’s the last time you let someone else win an argument without a fight (spouses don’t count)?  We don’t, it’s not in our nature. Since forever, we’ve been ingrained with the idea that we need every little personal victory we can get. Our positions are as good as our private property, and anyone who negates them is trespassing, and must be persecuted.

And that’s exactly how I felt, before today. I didn’t undergo some buddha zen thing. I was just wrong. Even now as I type these words, I want to qualify that statement, I want to say that I was only ‘somewhat’ wrong, or that I was just misunderstood.  But neither is true. 

I was completely, totally, and utterly wrong.

 

 

If you don’t understand it, Refactor it

 

It's a Zebra Horse. Literally.

I was recently asked to implement functionality that mimic’d existing functionality in our system, but was for a different type of data.  The two types of data share a common object heirarchy, so the task was a matter of changing something that was named ‘Zebra’ to a ‘Horse’. You could even say that the only thing that differed about the two types of data was their name and the specific database objects they interacted with.

I did the naive thing at first, and I used the Copy and Paste design pattern.  I went from zero to regret in less than three keystrokes.

Copy and Paste Design Pattern

Copy and Paste is a horrible design pattern. I used it at first because it would allow me to finish the task quickly. On the other hand, I’d have to go into hiding should anyone ever stumble across that code.  The only excuse I could muster is that the code should never need to change.

About halfway through this exercise, I couldn’t shake the feeling that I still had no idea what the code actually did.  I was a monkey pulling a lever, trying to get a food pellet.

It was sickening.

The books on my shelf started to laugh at me, Clean Code, Working Effectively with Legacy Code, and Code Complete all burned in the corner of my eye not unlike the ancient Sankara stones. As I struggled to withstand their withering glare, I knew there was only one option: Roll my sleeves up and learn what the heck the code was doing, and most importantly, Refactor it.

Refactoring when you have no idea what you’re doing

The trickiest part of refactoring is how long it actually takes to figure out what a piece of code actually does. Every name, every method, every property becomes a possible source of hidden problems. Just think,  If the code was well written, there’d be no need to refactor it.

To that end, I do four things when I need to refactor code:

  1. Determine what the purpose of the code was
  2. Draw UML and action diagrams of the classes involved
  3. Shop around for the right design patterns
  4. Determine clearer names for the current classes and methods

I spend most of my time on #4.  As Mark Twain said, The difference between the almost right word & the right word is really a large matter — it’s the difference between the lightning bug and the lightning.

If you don’t understand code, play with it. Try to refactor it. Create a branch and monkey around with it. Try to improve it. Most importantly, rename it.


ZebraHorse Photo courtesy of ***Karen and her Flickr account.

Know your terminology

Ikea Job Interview
Ikea Job Interview

I interviewed at a Web development firm recently; it was a nice place. Very anti-corporate, which if you know anything about me, you know I dig that

The interview itself was a ‘gang’ interview, with five separate personalities in the room (not including my own):

  1. The One that Made Me Feel Comfortable
  2. The Observer
  3. The-Quiet-Yet-Perceptive-One
  4. the Alpha
  5. The I-don’t-say-much-but-I-know-what-I’m-talking-about one. 

As it happens, the Observer was actually the Grand Poobah (Or Head Honcho, or Big Cheese, but I generally refrain from cliché in my posts. No. Really.), but he elected to remain quiet throughout the interview.

The interview itself ranged from questions about me and what I’ve done, to Questions I know the answer to, to questions I don’t know off the top of my head but when not surrounded by 5 people and really nervous I could probably answer, to questions I know I don’t know the answer to and said as much, and Zombies. 

I really wish Zombies had been brought up first.

P.S.: If I had known I could pick *any* weapon (real or not) to fight zombies, then I would have probably picked the Disc Launcher from Tribes.  Just hearing that whirring noise brings back memories.  As it stands, I think the Double barreled Shotgun from Doom was a good choice. If these are 28-days-later zombies, you’re going to want something upclose and personal because that’s where the zombies are.

Anyway, back to the interview: The Alpha asked me about CSS Selectors.  CSS-what? Keep in mind, I’m implementing a new layout for Stack Blog (that will replace this blog’s current layout), I’ve implemented stylesheets for my work on St. Anns, and I tweaked an already existing layout for Big Spring.  Most recently (read: last week) I created the CSS For the Project dashboard.

The question specifically was, “What are CSS Selectors?” My (stupid) answer? I don’t know. Or at least, I thought I didn’t. I’d heard the word, but wasn’t about to BS an answer.

Turns out I use them all the time, I just didn’t know what they were called.

If you’ve ever seen this:

#main {
font-family: Helvetica, Arial, Verdana;
font-size: 0.9em;
border: 1px solid #ccc;
}

then you’ve used CSS selectors. That thing up top, before the curly braces? That’s an ‘id’; specifically a div id named ‘main’. And it’s a selector.  ‘Selector’ is just a fancy word for ‘that which I will apply the style to‘.*  You can apply them to divs, html elements, and just about anything you want. You can even apply them to specific lines inside of Paragragh tags.

I learned an important lesson from that interview: Know your terminology. I’d been using selectors for years, but had never realized that’s what they were called.

 

*That’s only a smidgen of what’s really out there for Selectors.  Glancing through the list on this page, there are some formats I’ve used, and others I haven’t.  Of course, I’m not telling the full story, there is more to selectors than that. If you’re interested, this site goes through the nitty-gritty of CSS selectors.

Danger Phrases for Legacy Code

Warning signs in a software project rarely are found in code first. Just about the time you unpack your cubicle and get your development environment up and running, you will already have received warning signs about the application. Here’s what to listen for:

 

  • “The code is very complex.”
  • “Be careful when you make this change, it’s going to affect X.”
  • “No, we don’t have unit tests. Our code is too complex for that.”
  • “We have a global cache that takes care of all of that.”
  • “We don’t fully understand what that affects, so be careful.”

 

These phrases center around a theme: The code is really hard to grok and it’s chock full of dependencies.

Uh oh.

If you’ve worked in with enough legacy codebases, you’ve probably gotten used to that.  Get un-used to it. It’s wrong.  Code is only as complex as you make it. As Ernest Hemingway has taught us, you don’t need to use big words to tell a story.

Your code is not an exception to this rule.

Before you cast aside what I’m saying, think about it this way: If a human can communicate using nothing but the most basic language, and communicate effectively, then why can’t the same thing be done in code? Why is that the exception?

Can’t Install SQL Server 2008?

I tried to install SQL Server Management Studio Express 2008 today.

Going through that install process gives me a taste of the cruel world DBAs live in. I feel bad for those guys. No wonder they’re frazzled and grumpy.

I went to the SMSSE download page and was informed after downloading the program that I need to go to the Windows Installer 4.5 page and install the installer so that I could run the SQL Server Installer. My head hurts.

After reading tea leaves and conjuring up spirits with the Ouija board, I figured out how to install the Windows Installer.  At this point my morning took a turn. After dutifully restarting my computer, I ran the SMSSE installation process to have it tell me that my computer needed to be restarted before I could install SQL Server 2008.  It didn’t matter how many times I restarted my PC, it still failed to install.  I summed it up in a Twitter Post:

After searching the internet, I found the answer in a Microsoft Support Forum:

  1. Click ‘Start’ -> Run…
  2. Type: Regedit, hit enter.
  3. Navigate to: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerPendingFileRenameOperations
  4. Right click PendingFileRenameOperations and click Modify.
  5. Delete the value for PendingFileRenameOperations.
  6. Close the Registry Editor, the issue should be fixed.

After you’re finished, it should look like this:

In my case, it did and I was able to install SMSSE, just with a little less hair.


 

Looking for Chef Sanders in Borderlands?

claptrap

I was enjoying downtime this weekend after a few weeks of pretty intense work and sat down to play Borderlands, and having beat the game, I was just starting my second playthrough.  Claptrap came over the radio and told me that ‘Chef Sanders’ had more missions for me in the Arid Badlands.

Have you ever tried to google for ‘Chef Sanders Arid Badlands Borderlands’? Go ahead, try.  I didn’t get many hits either.  It turns out our little mechanical friend is actually saying Shep Sanders

Here’s where Shep Sanders is located:

World Cup House Rules

1. From 9 June to 9 July 2006, you should read the sports section of the newspaper so that you are aware of what is going on regarding the World Cup and that way you will be able to join in the conversations. If you fail to do this, then you will be looked at in a bad way, or you will be totally ignored. DO NOT complain about not receiving any attention. 2. During the World Cup, the television is mine, at all times, without any exceptions. If you even take a glimpse of the remote control, you will lose it (your eye). 3. If you have to pass by in front of the TV during a game, I don’t mind, as long as you do it crawling on the floor and without distracting me. If you decide to stand nude in front of the TV, make sure you put clothes on right after because if you catch a cold, I wont have time to take you to the doctor or look after you during the World Cup month. 4. During the games I will be blind, deaf and mute, unless I require a refill of my drink or something to eat. You are out of your mind if you expect me to listen to you, open the door, answer the telephone, or pick up the baby that just fell from the second floor….it wont happen. 5. It would be a good idea for you to keep at least 2 six packs in the fridge at all times, as well as plenty of things to nibble on, and please do not make any funny faces to my friends when they come over to watch the games. In return, you will be allowed to use the TV between 12am and 6am, unless they replay a good game that I missed during the day. 6. Please, please, please!! if you see me upset because one of my teams is losing, DO NOT say “get over it, its only a game”, or “don’t worry,they’ll win next time”. If you say these things, you will only make me angrier and I will love you less. Remember, you will never ever know more about football than me and your so called “words of encouragement” will only lead to a break up or divorce. 7. You are welcome to sit with me to watch one game and you can talk to me during halftime but only when the commercials are on, and only if the halftime score is pleasing me. In addition, please note I am saying “one” game, hence do not use the World Cup as an excuse to “spend time together”. 8. The replays of the goals are very important. I don’t care if I have seen them or I haven’t seen them, I want to see them again. Many times. 9. Tell your friends NOT to have any babies, or any other child related parties or gatherings that requires my attendance because: a) I will not go, b) I will not go, and c) I will not go. 10. But if a friend of mine invites us to his house on a Sunday to watch a game, we will be there in a flash. 11. The daily World Cup highlights show on TV every night is just as important as the games themselves. Do not even think about saying “but you have already seen this…why don’t you change the channel to something we can all watch??”, the reply will be: “Refer to Rule #2 of this list”. 12. And finally, please save your expressions such as “Thank God the World Cup is only every 4 years”. I am immune to these words, because after this comes the Champions League, Italian League, Spanish League, Premier League, etc etc. Thank you for your cooperation.

But We’ve Always Done it That Way

Author’s Note: It appears in the conversion from BlogEngine.NET to WordPress the code block was truncated. I have no idea what it used to read; but if I can find it I’ll edit it in. Otherwise, assume it was horrid code.

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 are also some other indicators in the code itself that tell us something about who wrote it: They used comments that explained what we already knew, and they used comments to close blocks of code, both distractions to understanding 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 unequivocally 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.