Hide and Seek: A Code War Journal Entry

I’m hiding. There are hiding places in this rough terrain, but I have an ominous feeling. The situation will tighten. I know I’ve bit off a bigger piece than I possibly could chew. Cutting that communication line will have them after me. They won’t rest until they’ve caught me. They may already be looking for me. I’d better stay hidden.

I don’t even breathe as distant noises condense into shadows. The shadows rake the terrain. Strange. It is as if they were not looking for me at all. What is this? I think I may have heard about this technique, but I though it’d still be in the far future. If they have that kind of technology at their disposal, I’m worse off than I thought. They are not looking for me, they go through each and every possible hiding place. The systematic search reveals everything. 

I think the shadows are special MAGIC troops. They mark each unnamed hideout on this field. The mapping is just the beginning. I know my camouflage will deceive them for now. I’m not hiding on the bottom of a standard foxhole or a normal bunker. I can see them all around me, though. They are constant features of this field. The MAGIC men leave.

I won’t have trouble hiding from the ELSE unit, either. That is because I’m not hiding at the root of a condition. The bark of the condition tree was used by local medicine men in their potions. The potions let them see different visions of the future. The medicine man used the visions to help the local tribe make right decisions. The tree must have some logical-psychedelic properties. The ELSE unit focuses almost robotically only on the branches of the condition. They search each hole. I’m afraid that the New Guy has panicked and forgotten his training. He will probably be found on a branch of a condition.  We had to separate, so now it is each man for himself. 

They have still not discovered me, but I fear it gets more difficult. They know there are saboteurs in the area, so they won’t give up. They know there are saboteurs everywhere, all the time. Suddenly, a periscope rises out of a nearby ditch! It turns and I know that a diver is checking the surroundings. Unfinished foxholes and strange shadowy places will be checked very carefully. The comment stream team specializes in rivers, lakes, creeks, and they can swim even in shallow ditches. This time they seem to use the TAG tactic (Terminating Ambiguities, and General unfinished business). They don’t have much to do here, that nearby ditch seems to be the only thing that holds any moisture on this dry plain.

If I make another half an hour, they’ll get bored with the search. I hope so at least. I swallow out of fright, when I hear the special forces vehicle parking close by. The side of the tank displays a word that chills me to the bone. With a militarily clear font it says “CLOSURE”. I wish none of us is hiding at the end of a bridge or tunnel. These men check each and every end. They operate on a clear principle. If a bridge or a tunnel starts from somewhere, it must also end somewhere. In principle bridges and tunnels are excellent hiding places, but that was before the CLOSURE forces arrived. Luckily there are not that many CLOSURE men about, because of the required high level of skill. No symmetrical end is safe to hide in when they are on the field.

I won’t be found by the PTHESES men, either, no matter how eagerly they run around with their bayonets out. I am not dumb enough to try to hide as the precedence table, a part of every field coder’s standard equipment, advises, in a logically questionable stack of conditions. You only need to stick your bayonet in there once, and you’ll sure hear of all hiders. Everybody knows the story of Second-Row Sanders. He had hidden himself in the braceless roots of an ancient condition and laid himself next to the only row there. He had drawn an indentation cover over himself for extra cover. He had not been seen in three years. He might still be lying there for all I know.

The last charge begins. When the detailed search is over, they move on to the bigger picture. The fire from the CALL cannons comes close. Shrapnel flies all around me, the noise is deafening, but I think I might still be in one piece. Silence descends on the battle field. I’ve made it! The terrain is filled with scars left by the special forces. An airplane flies over me from right to left. It photographs the whole area. Only the first phase is over.

I think I spoke too soon. The worst is yet to come. The picture of the terrain and all the markings of the special forces, the ticks, will be examined. The analysis will be conducted by a real expert, whoever built the destroyed communication line and designed this field. I know the statistics speak against me. Most of us will be lost at the analysis. The fate of many of us will be MiA (Missing in Analysis).

Who are we? We are legion. We are everywhere in code. We are carelessness incarnate. We are inattention encoded. We are misunderstood. We are exceptional. 

Who am I, you ask? I am nobody and I am everybody, I am Unknown Bug.

5 Reasons for Not Reading Code

Perhaps the most neglected Good Thing in software development is reading source code. Why should this be? Here are five reasons and a solution as conclusion.

1. Psychological Reasons
Why isn’t code read? Perhaps it wasn’t written to be read. Arguably the most important property of source code is that it works. Just functioning is enough, when we talk about a small amount of test code or writing a small utility program. In any larger project, the role of maintainability is extremely important. I would even say that sometimes maintainability is more important than function. [Open for comments. Do any of you Tick-Kings have an example? When is code allowed to be broken, if it is readable?]

If it is enough for code to work, why read it? The science of statistics tells us that the great majority will tend to go where the fence is low enough. These Norm-Nerds are not evil, they just work as well they can or their managers know to demand of them. Statistically a small minority will try to cheat and slither under the fence. They can for good reason be called Dark Coders. They fallen on the Dark Side of the Force. As small a minority will actively raise the bar. You, the Tick-Kings, the readers of this blog, are the best, last hope of software engineering.

Norm-Nerds often write code that just works. They never think of having to read their own code. Writing illegible code is only reenforced by the powerful expletives emitted by the Norm-Nerds when they have to read somebody else’s code. Every armchair-psychologist knows that own attitude colors the way we deal with other people. If Marjorie spreads gossip about secrets entrusted to her, she will most likely be careful about divulging her own secrets to anybody. If Marjorie can’t keep a secret, how could she assume other people to be able to do so? Because Keith cheats and lies even to his spouse, he must internally start from the assumption that everybody else is also a lie a a cheat. Because Mike is always painfully honest, his gullibility is easy to take advantage. He will believe everybody speaks mainly the truth.

So if code that I produce is illegible, how could anybody else’s code be any better? People don’t read unreadable code, even though just that should be read.  

2. Hunting Perfection

Why isn’t code read? There is no right time to read code. If you look for the perfect time to read code, you’re out of luck. According to literature and the wisdom of the software development community, the Right Time to read code is after the class is ready, before it is tested, after it is fully functional, as early as possible, later than the last change. 

                              “There is no right time to read code.”

Ernst Hauschka, a German writer, wrote something along the lines of:

“It is not the people who have time to read books, who read books. It is the people who like to read books, whether or not they have the time, who read books.”

I can’t say it any better.

3. The Unskilled Tend to Procrastinate
Why isn’t code read? It is easy to defer a task, when its contents are not clear. Norm-Nerds don’t know how to read code and what to look for in code. You’d think that because they know how to write code, they’d know how to read it. Reading a book as entertainment is a completely different thing than reading a book with the intent of writing a report about it. Critical reading differs from regular reading like the stripes on a zebra. Producing text is considerably easier than producing good text, which explains why Norm-Nerds are capable of producing code. Reading code critically requires skill and experience. 

4. Feedback is Socially Challenging
Why isn’t code read? If creating criticism is difficult, but delivering negative feedback might be even harder. Giving feedback requires social skills. Say what you like, but technically oriented people are not usually credited with the best social interaction capabilities. Every manager knows how hard it is to judge others so that they still want to continue working with an improved level of quality. You have to structure the criticism in a constructive way, but you must not disguise it too positively, so that it can’t be seen as criticism. Any self-valuing professional will ignore undeserved praise without blinking. 

When you remove the authority difference created by the hierarchy, and you have colleagues criticizing each other, you move in a delicate area. If you complain about small, careless mistakes, the writer may think you don’t trust them at all and if you complain about big mistakes, you might make the writer feel dumb. In neither case, feedback hasn’t been delivered correctly. Feedback must flow in a healthy work environment constantly. Everybody can improve all the time. 

5. Underrated Checking
Why isn’t code read? Norm-Nerds think that checking the work results isn’t as productive as writing new code. This reason probably lurks behind the problem of not testing enough. If you don’t consider a task high enough, it will never be prioritized to be executed. The value of a task depends on the results it produces, and if you can’t find valuable enough improvement suggestions by checking, you shouldn’t be checking. Instead of wasting your time on an inefficient task, you will be writing more code, whose natural value seems big, even though much of so called normal code would benefit massively from simply never having been written.

The Solution

Code gets read

-when everybody writes code for other people,

-when checking code is seen as an essential and vital part of software development,

-when people can read and check code,

-when the feedback generated is constructive and instructive,

-when the results of checking do clearly improve the current code (and all future code.)