Intolerance of Vision

I've always been the type who likes to look far ahead on whatever trail I find myself. When I can see some obstacle, it only seems logical to report back to whomever is in command so they can make appropriate plans. What I've discovered is that some commanders are allergic to news portraying events beyond their mental horizon. "It's not going to happen for a week/month/year, why do you want me to worry about it?" That's a fair argument when you're in the heat of battle but rings empty when you're safe at home, eating dinner in front of the fireplace or when the battle-stations alarm is constantly clanging in your ear because everything is a crisis.

To ignore what lies ahead takes one of two types of people. The first is constantly in battle-mode and never feels like the have the luxury of looking down the road. There are managers who take this to the extreme by operating in this mode all the time and make management-by-crisis their modus operandi. If it doesn't get immediate results, they're not interested. It doesn't matter if doing things the easy way now will create 10 times more work later, the mantra is "why is it taking so long and when can we be done?" Quality, safety, sanity, all take a back seat to expediancy. The second type of person has a devil-may-care attitude and lives with their head in the sand. Worring about what might happen is for those wet-blanket types who keep telling me what to do like "wear your seatbelt" or "quit smoking". Nag nag nag, that's all they do. Can't they stop whining and live a little? While the latter is a case of simple denial, the former is clearly one of short-sightedness.

This brings me to tolerance. Imagine if General Custer had had a scout who kept him informed on the location of the belligerent Indian tribes but Custer got so annoyed by the constant reminders of upcoming trouble that he fired the scout. Having such a low tolerance for long-range vision (of both good and bad news) becomes a grim mistake. Having kept said scout and charging ahead anyway is completely within a commanders decision-making authority. It would not prevent the upcoming catastrophe but puts the mantle of blame solely on the commander. The scout's responsibility is to report what he sees and would be derelict in his duty to stay silent. The commander will be responsible for whatever happens regardless but ignoring information snatches from his grip the haven of excuses and tightens the noose of history around the neck of his legacy.

The deluded commanders ignore harbingers of bad news while deranged commander shoots them. The pragmatic one listens but takes his own counsel. At the very least, having another warm body around means one more person you can hand a weapon when you've circled the wagons and are faced with a relentless oncoming horde.

Do you know someone with a low tolerance of Vision? It'll take more than a visit to the eye-doctor to take off the blinders and open their eyes. Let me know if you discover an effective vaccine for this particularly nasty disease.

Blood, Sweat, and Tears

Showing a fellow developer how to create JUnit tests for Java code, I came up with a saying. "Refactoring is a whetstone with which you can hone your design skills." Maybe I can come up with another good phrase that includes unit testing.

Being a Codewright is like being a blacksmith. While casting something in iron is relatively straightforward, it also requires much more prior planning. It also assumes that we want to make copies of an existing design. Anything custom means pounding it out by hand the hard way.

With much sweat and toil in the crucible of coding, we put code into the forge of the code review to make it malleable, we use unit tests like an anvil to support our efforts as we bring to bear the hammer of refactoring to shape the code to our will all the while evaluating how much work is needed to achieve the desired design.

So, when you hear your team banging away at the code ask yourself, is the noise they're making that of peices being moved around with fervent hope that "maybe *this* will work!" or are they methodically improving the code through the use of the forge, hammer, and anvil?

Or Else What?

So, I'm about to do some development on a project that will be using IBM's RAD7. In prepration, the developers are going to a RAD7 class. During class the instructor is dutifully showing us all the bells and whistles and he does this:

if ( somecondition)
{
return success;
}
else
{
return failure;
}

I thought I'd exhert some independence and remove the else block:

if ( somecondition )
{
return success;
}

return failure;

My code is equivalent to the previous example but I began to wonder how do you know when the 'else' clause is unnecessary? In simple cases like this one, it can be easy to show that it doesn't matter. Is this a case where we can make things less clear by being more explicit? Consider the example that uses the 'else' block; if another programmer were to come along and wanted to add more code, how easy would it be for them to decide whether to put the new line in the 'else' block or after it?
Could that question indicate that the 'else' statement is part of a code smell? I'm not sure what the smell would be called, I'm not entirely convinced that it is even a smell. What keeps bugging (ha!) me is how similiar it is, at least as a symptom, to why one of our code standards is to require braces everywhere even if they are optional. I might look this up in Scott Meyer's C++ books.

NON-STANDARD:

if ( chaporones_are_gone) drink;
cleanup;

STANDARD:

if ( chaporones_are_gone)
{
drink;
}
cleanup;

The braces are the safety-net to keep the programmer from inadvertantly making changes to code that isn't affected by the 'if'. The compiler will never be a replacement for a thinking human and since humans are fallible, it makes sense to develop habits that keep us from burning ourselves. How can we define a rule to keep us from overusing the 'else' clause? My initial attempt was something like "only use an else if the else block contains another if" but that doesn't really do it. Maybe when the condition includes something like 'Do x unless a=1' but

Let's add an alternative activity, dancing. If you converted the condition into English syntax, you could say "The teenagers will dance or drink depending on whether the chaperones are gone; in any event they'll have to clean up." This says we clean up always and isn't really affected by the condition. There are two exclusive activities mentioned. We never do both. What I notice is that the sentence has two verbs and one object. I'm having flashbacks to sentence diagramming from junior high, not pleasant.

This is related to the discussion about using negative logic in conditions. Yes, the order of the 'then' and 'else' blocks won't matter to the compiler but one way makes it easier for humans to read. Eliezer Yudkowsky discusses this in a Bayesian logic article using the example of why story problems can be so hard for students to understand.

In all the efforts to get programmers to use more powerful tools, maybe we can spare some time to hone our logic skills. However much we'd like expect our tools to do more work for us, there are some things that will always be left to the individual. Computers won't gather requirements for you. Humans can parse the customers requests and know what to take literally or when to use context to help with the interpretation. A sound foundation in the English language can be a powerful tool in the developers toolkit.