Archive for October, 2009

Else My Name Is Betty

No Comments »

“Software types are more analytical, (either as a result or as an cause of them being in their field). As such they see things that Joe Random doesn’t even notice. When the waitress says “If you need anything else, my name is Betty” Joe Random grunts and takes a bite of his meal. Programmer dude wonders what her name is if he doesn’t need any thing else. […] Computer types are so used to thinking about eventualities, undesirable consequences, dangling IF conditions, and protecting against them that they fall into doing so in personal life as well. A simple, carelessly worded question in normal conversation can render them speechless while the gears grind.” (icebike) [icebike, article]


Vorm en Kleur

No Comments »

“When I was a young boy” (Muddy Waters) [Manish Boy] my mother done told me, I was one scary boy. Mind we are talking pre PC era. Actually the IBM PC was still ten years a-coming. Yes, we are talking August 1971. I was at the age of five—just. Somehow I had gotten hold of my sisters “vorm en kleur” (shape and color) booklet. (I summoned all my google fue, but to no avail, so I can not show it to you here.) It was some typical ’70s teaching tool. vorm (shape) There were colored shapes, like red-squares, or blue-triangles. There, also, were “boxes” that would interact with the colored shapes, either changing a shape or a color. E.g., from square to triangle, or from red to green. kleur (color) I instantly absorbed the booklet and soon I was filling paper after paper with my own variations. I had generators, that produced a specific shape and color, no matter what the input was. I noticed that boxes could not handle all input draai-kleur (color-rotate) (i.e., the domain was limited), so I made up rules, like door-als-past-niet (pass-if-unfit) and designed draai-vorm (shape-rotator) boxes that would work for any shape and draai-kleur (color-rotate) that would work for any color. I would string boxes into more complex boxes. kies-pas (choose-fitting) I would draw boxes with multiple outputs, multiple inputs, an arbitrary input symbol (actually a question mark), kies-maar (choose-arbitrary, i.e., a non-deterministic box), kies-pas (choose-fitting, i.e., box overloading), duplicator boxes, switcher boxes, decider boxes (i.e., flow control), state-holder boxes and many others. The shear volume of papers littering my room, with all these boxes, really scared my mother—or it might have been my unwillingness to interrupt my journey for trivial mundane thins like eating, sleeping, social interaction and personal hygiene. Basically, that was when I learned all there was to know about input, process, output. Everything I learned about writing code later in life seemed a trivial continuation of “vorm en kleur.” And why am I laying this funky bit on you? Well, the original “vorm en kleur” system—not including my extensions—probably is the most complex thing a non techie, will be able and willing to understand. So it might be the perfect tool to explain the biggest known secret of systems design: The inside matters. Ok, a raise of hands, who amongst you pro-programmers has had trouble in the past explaining this to some manager? Ok, ok, just what I thought. Next time explain “vorm en kleur” and draw them this:
what we haveTell them: “This is what we have. This is what we need.” and draw them:
what we need If they don’t understand, just quit, seriously, run while you still can. You know why? Because that would-be-colleague that writes those “what we have,” by virtue of delivering some results that the customer came to accept, will be put in charge of designing the grand new integrated product that will be the apotheosis of all your company’s products (all in Python, mind) and “they” are going to bet the whole company on you saving the day while crediting your ex-colleague-now-boss. You will die a slow and painful death. You will die from battle fatigue—or maybe it will be the lack of time for those trivial mundane thins like eating, sleeping, social interaction and personal hygiene. And you want to know the worst part of it? You are sure, you want to know the most gruesome part? You know, you know what the worst part is, already. Right? Worse than dying, your legacy will be a big pile of shitty code. So… run… run… run… like a man.


P ⊆ NP

No Comments »

Turing Machine

Turing Machine

In computational complexity theory, P […] is one of the most fundamental complexity classes. It contains all […] problems which can be solved by a deterministic Turing machine using a polynomial amount of computation time, or polynomial time. [P-complexity] The complexity class NP is the set of decision problems that can be solved by a non-deterministic Turing machine in polynomial time. [Turing machine] “So P = NP means that for every problem that has an efficiently verifiable solution, we can find that solution efficiently as well.” (Lance Fortnow) [The Status of the P Versus NP Problem]
C’mon, don’t tell me you know all about the P v.s. NP stuff, including NP-complete, NP-hard, Pseudo-polynomial time, NP-easy, NP-equivalent, and the whole Complexity Zoo.


Bare Minimum Effort Loser

No Comments »

compLifeCycle“A sociopath-entrepreneur with an idea recruits just enough losers to kick off the cycle. As it grows it requires a clueless layer to turn it into a controlled reaction rather than a runaway explosion.”
“Sociopaths, in their own best interests, knowingly promote over-performing losers into [clueless] middle-management, groom under-performing losers into sociopaths, and leave the average bare-minimum-effort losers to fend for themselves.”
“Eventually, as value hits diminishing returns, both the sociopaths and losers make their exits, and the clueless start to dominate. Eventually, the hollow brittle shell collapses on itself…” (Venkatesh Rao) [The Gervais Principle]
If you are a good programmer, than you will be—by definition of the word: good programmer—perceived as “bare-minimum-effort” loser. It is the effort that counts. That is why you are left to fend for your self. So there, now you know.


Unlikely Potential Problems

1 Comment »

Photo of the 1988 source code of PAP (Pension Analysis Program).
Once—in 1988 to be exact—I, proudly, showed my dad the source code of a program—PAP, Pension Analysys Program, to be exact—that I co-wrote with an actuary. Not being a computer literate at all, my father looked at it with little interest, read part of it nonetheless and than said the most amazing thing to me: “Why are there so many errors?” I was baffled, many errors in my code? Looking at this one line—the one showed above to be exact—it hit me. The code was larded with ifthen Error(). I explained to my father that I tried to catch everything that could go wrong at the earliest possible moment and, with appropriate modesty, that it was a sign of quality code. I tried to explain, ignoring my fathers tell tale signs of boredom, that the Error() function would hardly ever be executed in the end product. I told him all about error distributions not being normal and their heavy tails not being exponentially bounded. I thought I lost him there because my father was not a math buff, but a financial-adviser. When I had finally shut up, he proclaimed: “So all you are saying is that you do not ignore unlikely potential problems. Good for you.”


Technology Debt

4 Comments »

If I hat to pick the one term that causes confusion in code companies, it would be “technology debt.” This metaphor, was coined at least three years ago: “Technology debt is basically when you ‘borrow’ time to avoid having to pay it now – but likely having to pay it later, generally with interest.” (Dharmesh Shah) [Development Short-Cuts Are Not Free] Compared to financial debt, technology debt is less tangible. Some don’t even think the metaphor to be very strong: “unlike real debt there is no external requirement to pay this back.” (Kendall Miller) [Technology Debt?] However I think that Kendall, as many others, is confused. This confusion might be due to the ingrained misconceptions that code mainly has functional-properties, and that each functional-property is implemented as a monolithic block of code. First and foremost, technology debt is mainly about the nonfunctional-properties, like re-usability, maintainability, robustness, security, user-friendliness, (source) controllability, compatibility, extendability, copy-n-past-level, correctness, and so on and on and on. If—as Kendall Miller seems to—one assumes code has mainly functional properties, technological debt translates into limited functionality. Functionality is like taste, “you don’t have to lay an egg to know if it tastes good.” (Pauline Kael) But if you don’t care what the kitchen looks like after making omelets, I want to be your maid nor cook. messy-kitchen-1 So two functionally-similar blocks of code have a similar technology deficit, so clearly one should pick the cheapest. This assumption gets you a techy techie, because, most every time a techie brings up non-functional technology debt, in what ever form, they are perceived as non-supportive, inflexible, uncommitted or worse. Understanding technology debt is difficult, but important. Misunderstanding it, can be catastrophic.


Feel the Magic

1 Comment »

PHPIf you write any, non trivial PHP script, that reads and writes tekst, you will need to get a feel for the magic in PHP. Because at some point, you start to wonder, where all those backslashes come from. Because quotes in text will grow backslashes with every read-write cycle, like this: \\\\\\\\\"Sure!\\\\\\\\\". So you set out to find out what is going on:

int fwrite ( resource $handle , string $string [, int $length ] )
fwrite() writes the contents of string to the file stream pointed to by handle.
handle:
    A file system pointer resource that is typically created using fopen().
string:
    The string that is to be written.
length:
    If the length argument is given, writing will stop after length bytes have been
    written or the end of string is reached, whichever comes first.

Looks normal so far, but directly below than it reads:

Note that if the length argument is given, then the magic_quotes_runtime
configuration option will be ignored and no slashes will be stripped from string.

But of cause, how stupid of me, clearly if I supply a length argument, I would not want to ignore the slashes (that were added apparently by some other “magic” functionality) and be happy to have them in my file, after all they are magic quotes from the great wizard that was born in Qeqertarsuaq, how could I not want that? Or maybe I am one of those exoteric inclined people that prefer solid design over “magic” kludges? But don’t tell anyone, or the last words I will ever hear are: “Stone him! He is the endoheresiarch!”
Read the rest of this entry »


Hard Sales

No Comments »

Source: BusinessBalls.com

Source: BusinessBalls.com

When you are a pro-programmer, you will know “Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. It’s just never going to happen. Get over it.” (Joel Spolsky) [The Iceberg Secret, Revealed] Hence, you live by the WNA-paradigm (give them what they Want, Not what they Ask for). However, the good people over at sales live by the opposite CAR-paradigm (the Customer is Always Right). This seems contradictory, and it is. It is also a recipe for success. A successful company will utilize abstraction layers . . . you know where paradigm shifts take place. Like: connection oriented TCP, based on connectionless IP. Client orientated CAR-sales, based on system orientated WNA-development is a prerequisite for a successful company. (Did I just say “car sales?”) As an abstraction layer, sales has to provide a CAR interface to the customer, based on the WNA interface you provide.
Read the rest of this entry »


Maligment Metaphor Mixing

No Comments »

source: Wikipedia

source: Wikipedia

Recently I was reading a book on algorithms and I had trouble understanding some example code. They were discussing breadth first traversal of a tree. Like the basic flood-fill algorithm, it is straightforward to implement with a FIFO queue. When it comes to linear ordered data there are at least three naming conventions for type and methodes: Vertical e.g. stack_t with push(), pop(); Horizontal e.g., queue_t with enqueue(), dequeue(); and Gyved e.g., list_t with putHead(), putTail(), getHead(), getTail(). You should not push down on a queue or dequeue from a stack, that is confusing. This was, however, exactly what happend in the book. It used a standard C++ library template called queue that has push() and pop() methods. To add insult to injury, the authors used the the name stack for their queue object. This made things far worse, because now there was one line of code that turned the whole interpretation 90°. I glossed over the code and started to wonder (wrongfully) why they were using a LIFO stack, turning the example in a depth first traversal. Only after re-reading some text and re-examining the code, did I spot the definition of stack as a queue: “queue<node> stack;.” Note that the C++ queue template uses push() and pop() but any underlying containers have to implement the oxymora push_back() and pop_front(). This was a very clear and short example. Imagine doing something like that in a real-life application.
So the lessons learned, again, were to never mix metaphors and to always refactor mixtures in given-code.