The Enterprise

The Traps of Obviousness

Michael Pankov •

Note: This text was initially intended to be a question on programmers.stackexchange.com, but I decided there's no "hard answer" and the question may easily be considered off-topic. So I'm putting a more developed version of it here instead.

There's an often attitude in software engineering: calling big, complex things obvious.

The problem is present not only in software engineering, it probably just happens more often there because of "high density of knowledge" in programming. The gap between knowing a single detail and not knowing it is huge due to many abstraction levels, which one has to deal with. Because of that, "full-stack" engineers are highly valued because they have understanding of all the layers of the computing system designed to do the job.

In any case, for the purpose of this discussion, let's not concern ourselves with other fields, and talk just about programming.

So, there's a common phenomenon: a person who is familiar and experienced with a particular technology (1) has a discussion with less familiar developer (2) and when (2) finds some disconnection between their understanding and actual workings of this technology, (1) exclaims: "It's obvious!". Of course (2) doesn't think it's obvious because it took some effort trying to understand the particular thing, which (2) may initially consider a quirk.
Situation I'm talking about is along these lines, although I'm intentionally exaggerating (but only a bit):
1: So, what's the problem? 
2: I'm trying to create a 2 billion-sized array of integers on stack in C, can't wrap my head why it doesn't work. (Doesn't know about limited stack size and probably doesn't understand concept of process in OS).
1: But it's obvious! (Does know the implications (2) doesn't know about).
In some extreme cases (1) may go as far as criticizing (2) for their lack of knowledge or even attack (2) personally.

Now, I think (1) behaving in such a way is wrong for several reasons, among which:

In any case, 

But there's also another sort of obviousness, illustrated by the following example:
1: Let's implement our custom test case description format! 
2: How should the long lines should be handled in this format? (Knows about C string literals, which can be concatenated, but also can be continued via `\`, and also remembers about Markdown, which continues every "string" by default (actually, a paragraph) and uses empty lines for line breaks.)
1: It's obvious that it should be done via `\`!
Here (1) behaves if not worse, then at least no better, than in previous case. They demonstrate a significant amount of ignorance by assuming there are no other options. They also imply that their solution is the best and is not on topic for discussion.

This is, essentially, the authoritative supervisor's way, leading to poor motivation of executor and misunderstanding. Apart from that, it results in bad design due to lack of attention to other ways to solve the problem.

I think every self-respecting programmer will agree, that stating the obviousness of the architecture, software design, or particular way to solve a tactical problem, as implemented or intended, doesn't help anyone.

This word — obvious — can only really be used as a pun, a joke, hinting to a really poorly designed system.

Footnote: It was probably obvious to someone, that -j option of tar means bzip2 archive format, -J means xz and -z means gzip.
comments powered by Disqus