Compilers Warnings Are Errors

I’d like to meet whoever invented the Compiler Warning.  I’d punch him.

No individual has done more hidden harm to programming projects than the guy who created the compiler warning.  Compiler Warnings are runtime errors that hide from you and laugh at you when you try to find the bug that’s keeping your code from being shipped on time.

Advertisements

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.

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.

Follow Through

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.

The most fun you can have in 140 characters

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:

 

I’ve also read countless blog posts by people I’ve follow, posted pictures on twitpic, and complained about bad User experiences.
Each week is normally chock full of interesting items and fun items. If you want to learn more about twitter, I recommend reading Brent Ozar‘s book on Twitter: The Simple Twitter Book.  He explains twitter much more clearly than I can (just not in 140 characters).

 

The Paradox of Safety

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.