Vorm en Kleur

“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.