Progress and Poopery

[substitute]

I lamented last year that we technology people at my job had created a not particularly complex system and in two years had totally lost our grip on how it worked, so that large portions of it were opaque and mysterious, with "No Touch" signs on them. This depressed me, and put me in mind of the general state of humanity and our poor collapsing Towers of Babel in which we take such pride, etc.

We rebuilt our Tower, using new and better tools, and rules that kept us from our previous folly. There were great resolutions passed, Five-Year Plans approved by the Central Committee. Happy days were here again.

We built a new system from scratch. Two months later, it is full of mystery and fear. People use the passive: "It keeps doing that" or "It doesn't seem to do this properly" or "I don't know why it did that". This is something we built! Our Frankenstein's monster, our golem, our own little Pokémon.

I predict this trend will accelerate, and the next project will be built at the same time that we fail to comprehend it, so that we're slaving away on incomprehensible tasks to build something we can't conceive in our minds, like Richard Dreyfuss building his Devil's Tower in the living room in "Close Encounters of the Third Kind".

Comments

Incomprehenso

[torgo-x.livejournal.com]

Once upon a time there was a strange man named Yizzle who made an HTML-parsing module that looked like it should work, but didn't.

I adopted it.

But I couldn't make it work either. There was much confusion and ennui.

The only thing I did that eventually got things working was that
I added lots and lots
of DEBUG > num and print "I'm about to do this...\n"; lines. So whenever I need to figure out why the hell it's doing what it's doing, I just change its DEBUG level from 0 to 2 or 5 or whatever it takes to reveal enough details.

Once I did that, turned up the DEBUG level, and ran thru some simple test cases, all the mysterious behavior suddenly revealed itself to be two strangely interrelating bugs.

This
explains some of it.

And basically: once I wanted to get a particular module's DEBUG level turned up, I just start my test-program with "sub That::Thar::Package::DEBUG () {6}; use That::Thar::Package;"

There's a few simple ways to make the debug level overrideable with an environment variable, too -- you can do like this:

package Kookoo;
BEGIN {
  if(defined &DEBUG) {
    # nil
  } elsif( ($ENV{'KOOKOODEBUG'} || '') =~ m/^(\d{1,6})$/ ) {
    eval "sub DEBUG (){$1}";
  } else {
    *DEBUG = sub(){0}
  }
}

You can even change hte value of DEBUG at runtime with:
"my $x = 0; sub That::Thar::Package::DEBUG {$x}; use That::Thar::Package;" and then alter the value of $x as needed.
(Altho this will slow the module down a bit, since no longer can the Perl compiler do compile-time optimization of the statements like 'DEBUG > 3 and print whatever;' since it can no longer tell that DEBUG is a real constant.

I don't know how it'd work in other languages, but the principles are similar.