… or ‘OO is hurting the industry because encapsulation’

The ability to abstract is a powerful one. I have seen my share of uni-freshers. There are a million different kinds of students and they all have their different ways of understanding. Obviously, some are better than others, and some are worse.

The worse kind of students are those who cannot abstract. Of course all human beings can abstract to some degree or other, otherwise no one would be able to drive a modern motor vehicle, or eat a pie. But some students insist on ‘knowing all the details’ because ‘that’s how they understand things’.

To those students, the concept of an API is difficult to explain.

‘You call this method, and fun things happen.’

‘But how does it happen?’

‘You shouldn’t care.’

‘But I need to know!’

And there are sighs. They most likely won’t pass 101, or if they do get through, they’ll be miserable for the rest of the course, unless you’re a hot chick and have a full set of 14 geeky Asian guys to help you out with the assignments.

There are a couple of explanations that can be offered for this. Most people, even some experienced developers, tend to side with one explanation: they are bad at abstraction. Without it, you won’t get far.

I beg to differ.

The reason why they won’t do well is that they are asking clearly the wrong person. They should not be asking lab demonstrators, who in all their infinite (well, 2 extra years’ worth of) wisdom, have no clue about how that API works. They should be asking the professors, the writers of that API, internet forums, or read the documentation, whatever. The information is available, but not from the lab demonstrators who get paid 13 dollars an hour including tax.

Their weakness is lack of confidence that stops them from asking difficult questions to the proper authority, and laziness in their quest for information.

Look at the top students on the other hand. The chances are, they fully well know how their favourite APIs work underneath the covers. They probably know how the chips are manufactured, how gates are made, circuits are designed, machine code is executed, assembly code is written, compilers are architected, and so on, and so forth. All the way up, all the way down.

My point is this: abstraction is a powerful tool, but it’s only a tool and it’s only one of the tools.

To pretend that the students ‘shouldn’t care’ about how an API works is at best ignorant and at worst, well, just ignorant. Of course they should fucking care, you know? Like Knuth or Dijkstra or someone rather really important once said in one of their immortal essays, although what we produce is computer code, we should never forget that what we’re really crafting is the behaviour of the machine. The runtime matters. It’s the thing that we’re trying to get the computer to do.

How else, other than finding out what your function call does, are you going to determine what the computer will do? Reading documentation is fine and dandy, but that guarantees neither the completeness nor the correctness.

You will never learn how to fix a car by reading the owner’s manual, or even the repair manual, or even the blueprints of the car straight from the manufacturer. You have to open it up. Take the wheels off. Lift the car from its axle. Pry open the diff. Feel how broken that bearing is. Shake it and see what sound it makes. That is how you learn how to fix something. That is how you learn _anything.

Furthering my point, I make this claim: Currently, the ‘abstraction’ is severely overrated, especially in OO- and component-oriented programming circles.

What they write is this: the blue button makes it go. The red one makes it go faster. Do not press them at the same time. That’s the extent of the 90% of the API documentation there are.

And they expect us to work with it. What if you want to make it go slower? The trick is to press the two buttons at the same time, except for in the next minor version update, pressing the both buttons at the same time makes it blow up, and you’re punished for using an undocumented feature.

‘We told you not to’, says the smug author. And we agree with him. All the OO people agree that this is the way it should happen. Don’t do things that you’re not told to.

But hang on a minute. Don’t you think that’s even slightly weird? Why such change in behaviour? Why did it make it go slower in the first version? What deficiency in the original design prompted the authors to make such changes? Wouldn’t you want to know? Wouldn’t you be curious?

Most of all, wouldn’t you be pissed off if it broke your app?

But no. We’re told it’s just like a contract between two entities. You keep to the words, and don’t do things that are not specified it in the contract, or there be consequences.

Bullshit, I say: in the real world, if pressing those two buttons made things go slower for more than 12 months, it would be in the de-facto go-slow-mode contract, which would be enforceable. The wordings of the contract itself be damned.

The proper way to make things would be to let people know why and how the things work. Abstract it, document it, that’s all fine, but do not hide how and why things happen. Craft every bit, every level of the application correctly, thoughtfully. Then let people see it. Let people see your fucking craftsmanship. If you ain’t got one, this is a very good time to get one.

This brings around me to the final point: although I started off this article by talking about abstraction, it’s not about abstraction as such. It’s about hiding behind it and thinking that kludge is OK as long as you stick to the contract, the API, the interface, whatever.

People don’t think in terms of contracts. They think in terms of behaviours, hows and whys. When you ring up your ISP, you don’t have the service contract in your mind. You want the internet to work, and you want them to keep quiet about your midget-porn download usage. Fuck the contract. Who gives a shit? Who even reads them? If they didn’t have the explicit midget-porn-secrecy clause in their contract, and if they spill the beans, you’d be furious, wouldn’t you?

So there. Be honest, write good code, let people see what’s going on. Do not hide behind the encapsulation. If you do, you’re a midget-porn lover.

.J

I enjoy it, although it’s bitter and often hot, sometime sour and more often that not, just foul.

For me, there exists a cup of ‘platonic’ espresso, in which everything is good, no bitterness, no scalding heat, no aftertaste of chlorine, no burnt beans, no old beans, just … you know, coffee.

It is my firm belief that any realisation of this platonic coffee can only take away from the perfect, ideal, platonic version of itself. Brewing a cup of coffee is a process in which you try your very best not to deviate too far away from the logos of coffee.

But recently, as my coffee brewing skills improve, I started enjoying coffee a bit more. May be even a bit too much. I solemnly confess that there were a couple of cups of espresso last week that I even found to be wholly enjoyable. No, no, this won’t do.

Much like the platonic and real coffee, digitised images suffer from a similar problem. That is, there is the ‘perfect image’, which is, obviously, the scene which was photographed by God, then there are ‘realisations’ of the image, which are taken by real cameras. At the very moment we take the picture, there are imperfections. Dynamic ranges are lost, colours and definitions are inaccurate, and so on.

This is entirely excusable. We do not want to blame the coffee farmers for not having the God’s One Coffee Tree. Camera manufacturer are good people, making a lot of money, having an interesting, satisfying job.

However, there is one chronic and inexcusable place in which to introduce further imperfections; and that is the rendering time – i.e., when the digitised image is displayed on the screen. It is akin to going through the trouble of getting the beans all the way from Java (where, as we all know, where God once planted his One Coffee Tree), then not having hot enough to water to brew the coffee.

I mean, imagine: A perfect moment happens somewhere in the universe. This moment is unique in space-time, nothing EVER, ANYWHERE will be exactly the same. It happens once.

Then there is the perfect photographer, who, using his powers of divination, predicted this event, and set up his camera.

When the moment came, he pressed the shutter. The clockwork of metal and plastic and copper and nylon, electrons and spring completes its circle within one one-hundred-and-twentieth of a second. Oh, no, Nikon engineers made a mistake, got past the QA person, it was more like one one-hundred-and-nineteenth of a second. Zeiss engineers, also, made an imperfection on the lens, which smudges lower right hand corner of the image, very slightly, almost unnoticeable. There was one speck of dust on the front element.

But the moment is captured. It has 14-bits per channel. There are three channels. There are more mega-pixels than there are brain cells in the average photoshop user.

The pain begins. Like every other aspect of photography (and coffee) the process is continuous subtraction from the perfection. The art of subtraction leading to its own, less Godly and more human perfection. As the roasting of the beans is the subtraction of the freshness, the cropping subtracts part of the perfection, leads to a more concentrated whole, and so on, and so forth.

And after hours, days, months of hard work and pain and blood and sweat, the product is ready…. and it’s a fucking jpeg.

It can display 256 levels of red.

Jesus Fucking Wept.

What’s funnier? The modern LCDs. You’re lucky if your panel can display more than 100 shades of pure red.

Ok, here’s the technical part of this blog:

1. Invent a file format that contains arbitrary bits per channel of colour (TIFF does that? good. I don’t know).

2. Given that the current generation of graphics can do only 8 bits per channel, but it can do 60 frames per second quite happily, we map the x-bit per channel into 8-bit, but randomise it over time. So when the average is taken over a second, it reproduces the original colour.

3. Add extra room for oscillation to cater for the shitty displays. The net effect will be a still photograph that looks like having motion-picture film-grain.

4. Not sure whether this will actually lead to a better looking image.

.J

And for those who didn’t enjoy it: I still think that you might be decent human beings, but by God, what’s wrong with you?

But now that’s out of they way, what I want to write about today is about the ‘standardisation process’. If you do not like the topic (like I don’t) or believe it irrelevant, you may stop reading now.

Plato, when asked the question of ‘Who will watch the watchmen’, he said that they themselves will, because they will believe that they are better than the other people. Through this egotism and alpha-male altruism, Plato believed, that the society could have a safeguard against failure.

What an idiot.

Government-sanctioned technical committee are a bit like that. They are entrusted (and that’s where the word comes from) by the people to produce something useful, and what they produce will have large legal, technical and financial implications.

If the enforcement is the person wielding a hammer, and the law is something that gives him the right to use it, the committee decides what the hammer is made of.

And the answer is not always as straightforward as you might imagine. What is the manufacturer of Egyptian cotton doing in this committee?

The year was 2005, and I found myself at the round table of a HISO committee. I was to write the draft standard for what would dictate how various health-IT organisations in New Zealand would exchange electronic data.

I was a software developer with four years under my belt - which is like fucking forever, right? - and for the first time in my life, had a ‘team’. (I was cocky enough to call myself a ‘senior software developer’ or a ‘technical lead’)

I was bulletproof.

I made jokes about the committee and others around me laughed with me, but I believed firmly that I was in the committee because I was better, I knew better, and I could lead all of them to a better place.

And by God, how quickly the power corrupts. And by God, what an idiot I was.

The first thing I did was to grab the requirement specification document of the product that we were busy implementing, deleted all the trademarked words, and submitted it as the draft standards document.

It had holes in it, it had some strange decisions that were not fully justified (or justifiable), it was still in pre-alpha stage of development, and it was all around propriety, ignored all existing related W3C standards. But it works, ok? Isn’t that what’s required of the committee?

My ulterior motive was to get my document accepted; that would mean I wouldn’t need to implement a standard; my programme would be the standard. Everyone would want to buy a copy of my software; it will be the only one available; and you’ll be required by law to purchase a ‘standardised’ software.

Looking back now, I see that pushing an ulterior motive through a committee is impossible. On the other hand, blocking other people’s motives is dead simple: stall.

There are four all-day meetings a year. And by ‘all-day’, we mean about 4 hours long. first hour will be spent on recapping, the middle two on lunch, and the last hour on organising the next meeting. There is very little stalling to do.

They stalled me, I stalled them. All along the watchtower, watchmen were busy stalling themselves.

I’ll save you the details. It’s not interesting. What I want to say is this:

Do not attend a committee with an ulterior motive, because you won’t get it through, and you’ll make everyone else’s life a little bit more pointless. It does not matter whether you think it’s clever (it’s not) and it’ll work (it won’t) and other people on the committee are idiots (so are you).

If you have an ulterior motive, go with a little bit more direct approach. And yes, I’m fully condoning the use of violence and blackmailing.

[...] they are SLOW.

I couldn’t agree more.

In all seriousness, however, I should point out that from my limited experience, WordPress just deleted my post, that there are differences between a bespoke development project and a generalised solution/product development.

For a bespoke development, I couldn’t agree more that we simply don’t write that much difficult code that is worth testing.

In a generalised product that is supposed to work out of the box, configure itself in a foreign and what must be considered harmful environment, facing endless molestation and little games of feeding ‘funny’ shaped input, unit tests are extremely valuable.

I must add, though, that even in this case I believe that ‘a Java class as a unit’ is a ludicrous notion. I’m talking about at least a package/assembly, or a whole component that could be made up of several of those. I know by now I’m no longer talking about unit tests, but hear me out:

I once wrote a system that takes XML and generates Java code, that compiles against a Java library (also written by me) and supposed to do something. There were tests written about really really anal behaviours, such as ‘what if the user adds 59 minutes to 2AM just before daylight saving’ and so on.

Some time later, we had to port our system across to C++, and of course we didn’t have a requirement specification. The C++ guru we specially brought on board went “what the f?”

But when I explained that we had test cases and all he had to do was to write the program so it passes the tests, he went “ok”. And lo and behold, it was so.

I guess in the end, this anecdote really had nothing to do with unit testing.

Secondly, the title of today’s blog is a lie: My cat did not bring anything last night, and I do not have a cat.

Which leads to my third point:

Technology is a lie, just like my cat.

I really should clarify: current generation of business computing technology is a lie, just the same way my title was.

There is no ‘technology’ going on. We have run around in a giant circle past ten years, relying on hardware manufacturers to accommodate for our ever bloating layers of layers of abstractions upon abstractions. We still rely on HTTP, and AJAX is a (very shallowly) glorified <iframe width=0 height=0>. Development of the languages that we use day-in day-out has been making something that looks like C behave more like LISP.

Technology. Give me a fucking break.

Technology is defined as ‘the application of scientific knowledge for practical purposes, especially in industry’. What part of what we doing can be described as ‘Technology’? If any among you want to cry out ‘it has adopted a new meaning because languages change’ just fucking shoot me in the eye now.

There is no ‘Computing’ going on, either. Current generation of computing has as much to do with computers as the current driving has to do with horses.

If you take a long drive down the lane all the way to the wops, you might hit one.

We write a few eXtensible Markup Language Documents, that is to be read by some program being run on an interpreter running in a virtual machine running in a virtualised environment. Sometimes I do wonder whether it’s virtual machines all the way down.

But anyhow, the fact that computers don’t do any real computation shouldn’t come as a surprise to anyone by now.

Then there is Business; Business is the last thing we are worried about in any given day. How often do you gloss over a bug, a feature, an unimplemented button, saying to yourself or to a colleague or a manager or a client saying ‘that’s a business problem.’?

How effing often, do you really worry, care, think about, talk in terms of, the business, the final product that we are supposed to be delivering? How often do you brush this thought aside for someone who knows better, deep down fully well knowing that there is NO ONE who understands it better?

Business, whether you, a J2EE developer, an ASP.NET developer, SQL junky, Javascript monkey, whatever you might be, like it or not, is what differentiates you from John F Carmack…. and also the fact that he’s good enough to have made it and owns Ferraris which is also his middle name by now, but that’s beside the point.

Let me start the paragraph above all over again.

Business is what differentiates us from other sufferers of the modern computing technologies. Whether we like it or not, as long as we are in this field, and pretend that it’s an application of science and that it’s going somewhere and the world is not made of turtles all the way down, we bloody well should care what we are applying it to.

Every line of code of Java or .NET that you write, wishing that you were writing a new breakthrough algorithm that will  turn the world into a giant bathtub filled with supermodels and peanut butter jelly sandwiches in Ruby, is killing baby Jesus.

If you are going to do the job and get paid for it, start caring. Start firstly from the first word. Start from Business. Then care about computers, then worry about applying science. If you don’t know any science, like I don’t, stick to the first two. Please to cease and desist to pretending, or start to learning, if you will, why not.

Please become an expert in your domain. If you are in insurance business, please understand how a broker works, what an underwriter does, who processes a claim. If you are in health IT, learn about ICD codes, learn how hospitals operate. If you’re in banking or accounting, please know what Basel-II and IFRS are (if you still have a job, that is).

Because then you’ll write better software, and your work will be more focused. You’ll ask fewer stupid questions. You’ll become far more valuable. I’ll curse a little less when I use the software you wrote.

That is all I wanted to say.

And of course, I’m saying all that to myself.