Never require the presence of a variable which isn’t used in your code.

I would think this would go without saying, but I just lost most of a day trying to figure out why a web service wasn’t working. One of the things I’d done was cleaned up some old code, including removing a hardcoded HTTP header value. The header it referenced wasn’t consumed anywhere in my code, and a quick smoke test indicated that, no matter what the value was set to, the client services behaved nicely. So I assumed (correctly, as it turns out) that the variable wasn’t used in locally or in any system in which we integrate, so I cut the reference out.

Rolled up the build, sent it off, moved on to other things.

QA failed the build, because one of the integration use cases was broken.

Turns out that unless that header is present, one of the methods in a client web service dies. It doesn’t matter what the value is, but it has to be there, or the web method chokes.

So, moral of the story: make sure that all your variables are really needed. Make sure they they mean something and cut out any variables which aren’t required. This is especially true with integration situations like those found in web methods.

Posting’s going to be abnormally slow here the next two weeks. I’m currently ramping up into a new project at work while another one is just winding down. While there’s overlap, I’ll probably be pretty busy. There’s also some Good Things in the works about which I’m reticent. I’ll post more about them if they pan out.

I do, however, have a few posts in the works about a variety of things; Quines and the CLR and hacker drama, oh my!

So stay tuned. But while you’re staying tuned, here’s an intersting quandary:

So the game Flood-It (to which I’m fair addicted) has recently been proved NP-Hard. The game is fairly simple. From the abstract of the linked article:

“In this game the player is given an n by n board of tiles where each tile is allocated one of c colours. The goal is to make the colours of all tiles equal via the shortest possible sequence of flooding operations. In the standard version, a flooding operation consists of the player choosing a colour k, which then changes the colour of all the tiles in the monochromatic region connected to the top left tile to k. After this operation has been performed, neighbouring regions which are already of the chosen colour k will then also become connected, thereby extending the monochromatic region of the board.”

So my question: what constraint of the above problem, other than finding the shortest sequence, could one relax or eliminate to move this problem from NP into P? I strongly suspect that, were a player allowed to choose their starting square after having seen the initial board coloring, that all board configurations would be solvable in P. I haven’t proved this yet, though, so I may very well be wrong.

Thoughts?

Interesting tidbit I found while brushing up on Big-O analysis – apparently some methods are O(a(m,n)) where a(m,n) is the inverse Ackerman function. It’s also sometimes written as a(n), if the two inputs are equal. This function does grow (so it’s worse than constant time) but it grows so slowly that it can almost be ignored.

a(n) will not grow larger than 5 for any number which can be written in the physical universe.

An example of an algorithm that demonstrates this is Chazelle’s algorithm for minimum spanning trees [pdf], which is O(e*a(e,v)) where e is the number of edges in the graph and v is the number of vertices. So it’s functionally O(e), but not quite.

Interesting, if useless.