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.
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.
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.)
