
Blind faith (computer programming) - baskind
http://en.wikipedia.org/wiki/Blind_faith_(computer_programming)
======
DanielBMarkham
This might be a good time to remind folks of Markham's Rule of Technical Debt:
_The economic cost of making your code better can never exceed the economic
value of the code to begin with._

Write a function that saves to disk but never checks if it fails? Who cares?
If you never use it again, or it never does anything of value to anybody, it's
not worth anything.

Craftsmanship is a great thing, but it always exists inside a larger economic
context. The guy laying tile in your kitchen doesn't give the same attention
to detail as the artisans completing the Sistine Chapel. And this is a good
thing! He might not have much education, he buys pre-assembled pieces, and
he's liable to just slop it in there. This is appropriate because your
bathroom's economic value is miniscule compared to a great cathedral.
Likewise, if you're in a startup writing code, you've only got a 1-in-10
chance or so of your code ever having any value at all beyond just playing
around. Completely different picture if you're being funded by BigCorp to
write version 8 of the Bells-And-Whistles App. Yet some of us insist on
treating all this coding the same.

So I am a bit annoyed at the use of the word "faith" in this context. If
"faith" is calling functions and expecting them to either execute or terminate
the program, CS is replete with faith-based-coding. This entry describes the
situation too much in loaded terms.

------
octo_t
I don't quite understand this (or rather why this is a wikipedia page). This
is literally "blind faith" as defined by the normal wikipedia page; there is
not "Blind Faith (electrical engineering) or "Blind faith (civil
engineering)".

Also the recommended alternative does not _have_ to be TDD, that is just one
engineering practice. One can develop with tests without it being TDD.

------
asveikau
I think most of us have probably deployed fixes without knowing 100% whether
it helps, but based on a good hunch from looking at data and code. The reason
I keep doing so is because so long as the hunch is good and based on facts, it
keeps working.

Tests are good, but there are always those issues those 0.001% issues that
will never occur when you are trying to make them happen, but will happen to
_somebody_ once code is deployed. I am reminded of an incident a few years
back where I could reproduce it with tests occasionally, but it would
literally take me weeks of re-running the test 24/7 before I would hit it
again. As you can imagine, I applied some "blind faith" (as in article) fixes
while waiting for that stuff to run.

PS: By the rules of wikipedia, this article probably shouldn't exist.
Nonstandard terms, not notable, original research, blah blah blah.

------
ams6110
_A programmer calls a subroutine to save user-data on the hard disk without
checking whether the operation was successful or not._

This might not be blind-faith. "Fail-fast" is a legitimate pattern where you
don't check for errors, you just let the program fail/terminate immediately.

~~~
Athas
But in this case, if you don't check the return value of for example the
write() system call, it's more a case of "fail silently" than "fail-fast",
which is perhaps the most dangerous form of bug that a program can have.

------
frou_dh
Not everything needs a snappy moniker and a Wikipedia page. May I suggest the
noun "carelessness".

------
AYBABTME
Also read Voodoo programming[1]/cargo cult programming[2].

[1]: [http://catb.org/jargon/html/V/voodoo-
programming.html](http://catb.org/jargon/html/V/voodoo-programming.html)

[2]: [http://catb.org/jargon/html/C/cargo-cult-
programming.html](http://catb.org/jargon/html/C/cargo-cult-programming.html)

------
_delirium
Reminds me of Knuth famously publishing some code he had never run, with the
disclaimer, "Beware of bugs in the above code; I have only proved it correct,
not tried it."

------
lambtron
Definitely a victim of this. Many times, when optimizing for time.

------
lcedp
But wait! Shouldn't file system subroutine check if it actually written what
was asked thus marking operation as completed successfully.

Why do we have bloody exceptions if we need to double check every action
taken?

~~~
asveikau
I actually find it much easier to code reliable stuff in C where you have to
check error conditions manually. If for no other reason that it serves as a
constant reminder that the failures happen, and if you're writing reliable
software this forces you into consistent habits to handle them.

I feel like in a language with exceptions, since throwing and catching happens
inconsistently and haphazardly all around a code base, people are conned into
thinking the exceptions will never happen. Usually one of two things happen:

1\. The language is like java and it forces you to declare what exceptions you
throw, so lazy people just put in lots of do-nothing catch blocks to silence
the compiler.

2\. The language doesn't have the "checked exceptions" concept, so people
literally think no exceptions can happen. They just wait for the exception to
make everything blow up.

Often when exceptions _are_ handled, this lack of explicitness makes sure it's
done at totally the wrong stack frame to make the judgement call about what to
do about it. Then some people do dumb shit like try to catch things like stack
overflow exceptions which should rightfully take down the process, and keep
running. Not to mention that an exception is just a wacky concept, it's
essentially a goto that crosses stack frames... Everyone criticizes goto, but
few people will question exceptions...

------
rfnslyr
My entire Computer Science education summarized. Blind faith. Every test,
every question, every function, every call. Blind faith.

------
baskind
TDD FTW!

