
In  2017, UK water companies still rely on “magic” - edent
https://medium.com/@sallylepage/in-2017-uk-water-companies-still-rely-on-magic-6eb62e036b02
======
SamReidHughes
In engineering you've got to do whatever it takes to solve the problem.

If you ever have a really tricky bug, try printing out the entire source repo
on origami paper and laying out the sheets in a Hilbert curve pattern on the
floor. Then throw out some silicium sticks -- one for each thread you were
running -- and 63% of the time, one will land on the buggy line of code.

~~~
kunimu
The most strange bugs have the strangest solutions. Just an hour ago I was
trying to debug a queueConstructor (it returns a malloc'd pointer to a queue
data structure), right after I finished implementing the operations for a
stack data structure. Malloc was inexplicably causing the program to hang (I
don't know if it's a segfault, I was using Windows). printfing around the
constructor and inside it didn't work. I had included all the libraries I
needed to, syntax was good, no warnings, I even changed the declarations from
int _var to int_ var.

It turns out the problem was that in main() just before I called
queueConstructor, I added the item 633346 as an integer element in my stack
data structure. Whether this overflowed the integer, I don't know. But I don't
know why it would stop malloc for a different data structure stored in a
different variable from working (perhaps it was occupying some memory that my
queue wanted?).

This isn't the first time bugs like this happen, and as a novice programmer I
really wish tools were better, or I knew how to use the tools. GDB available
via CodeBlocks wasn't helpful.

~~~
flukus
That sort of magic isn't right and if you don't find the source then you'll
probably end up with more and more weird bugs down the line, to the point that
nothing will work and you won't know why.

My first suggestion would be to familiarize yourself with valgrind to make
sure that you aren't accessing memory that you shouldn't be. Next would be
writing tests so you can isolate problems like this.

When you've got 58 different systems interacting you'll occasionally come
across some weird problems that you can't replicate, but they should be few
and far between.

------
castle-bravo
I like to think that dowsers are really a secret guild of hydrologists who
make a show of using magic to account for the uncertainty inherent in finding
things underground.

------
mathiasben
reminds me of this fake bomb detectors episode, also sadly from real life and
not some farcical dark comedy -
[https://www.theatlantic.com/international/archive/2016/07/ir...](https://www.theatlantic.com/international/archive/2016/07/iraq-
fake-bomb-detectors/490088/)

~~~
BrandoElFollito
Also Michael Shermer: Why people believe weird things
[http://go.ted.com/E35Jfg](http://go.ted.com/E35Jfg)

------
jlebrech
the magic happens in the brain of the user not the rods.

the brain can sense a lot more than we think.

~~~
dv_dt
Yup, I mostly think that once an area dowser gets experience in where past
pipes have been laid, then they get better at guessing on their next call.

~~~
jlebrech
hunch detector

~~~
dv_dt
Hunch detector yes, but also human experience with how past pipe laying
decisions went. The past people making those decisions weren't just making
randomized decisions - they were likely thinking about property lines, and
about of running through difficult to dig areas or likelihood of areas that
might get dug into unintentionally. Humans interpreting humans, sometimes
using talismans to focus an unconscious thought process.

It would probably be made into a better performing process if they got rid of
the tokens, and someone thought about it, wrote up what they thought past
layment decisions were based upon, and taught others as well as evaluated how
well that worked, but maybe not worth that level of formalization/optimization
either.

