SDK

In The Beginning

A: You know, I can’t deal with code that’s not correct.
B: But what is correct code? Isn’t the correctness of the code defined by the usage?
A: Yeah, that’s for sure, but you know, there’s still the ‘correctness’ in the code. I can’t leave a code behind that is not correct. Something that’s broken

Who hasn’t had this conversation? Of those who haven’t, who hasn’t heard it from other people?

There are more than two kinds of programmers in the world. Today, though, I’d like to pretend that there are the two kinds. Those who are happy with the code when it’s good enough, and those for whom enough is never enough.

And no – this is not going to be one of the fit-for-purpose arguments. The whole notion is self explanatory, and to be completely honest, I find it slightly condescending. As professionals in this field, it’s not like we don’t understand the concept of boundaries, parameters, conditions, constraints, and other things that inherently limits us and our code.

What I’m interested in, is where we derive this notion of ‘correct code’ from. There are many books written, many more guide lines set and countless hours of code reviews done, all for the search of the correct code. All this, without really ever having a satisfying explanation – not to mention the definition – of the correctness of the code.

In the beginning,

there was, or as it seems; there was, the correct code. Shown to us earthly beings by the higher powers, revealed through the dreams of the highest, righteous ones such as Ada and Dijkstra. They, our forefathers and priests, were the bridge builders between the world of us – the programmers, and the realms of pure logic and computation.

The computation was platonic. Numbers were integers. Computers were ideas.

‘How might we add numbers?’ Asked a money lender.

‘You enter one number here, and the other number here, and turn this handle.’ The righteous ones answered.

The money lender did his calculations. There was much rejoicing.

Then an astronomer came along, and entered the distance between the sun and the earth, then the distance between the earth and the moon, and turned the handle.

The great computing machine, at once, started steaming, then crashed and burned. This event marked the birth of something known as the ‘representation’. The computation had fallen from the realms of pure and accurate integers.  Unsavoury things such as precision, FLOATING precision, LOSS OF FUCKING precision, and others, came forth from the mouth of the ‘representation’ in a torrent of vomit.

The numbers we meant was, if you will, the will of the computation. The numbers we entered and the numbers that came out, were the representation. This idea, naturally, was met with much disgust. Many people tried to pretend that this was merely a passing idea, and that once we get finer cogs and smaller gears and stronger handles, representation will get closer and closer to the will, and all will be good, and we’ll be able to enter the Garden of Eden once more.

This day, alas, never came. In the meantime, though, the duality of the computation became the norm. The representation was not going away, and even though it was still vomiting forth the torrent of unsavouriness, people had grown to accept them.

The will, or the requirement, was correct. Representation that faithfully conveyed the will, was a correct program. Requirements were romantic.

Then came the War, and everything changed. It was almost like a back pedalling by the community, almost as if they were gripped by a nightmare. The will was not enough. It was not correct enough, they said, because it’s not done in UML.

What is UML? Asked a few. Most of those who asked were sent to the Camps. Those who escaped – the lucky ones – were captured soon and promptly burnt at stakes. Lucky bastards.

The tyranny of FORM and DIAGRAM and ARCHITECTURE and PATTERNS and CAPITAL LETTERS swept across the world, sometimes like the Black Death, and sometimes like the Pneumonic Plague. Sometimes, less often, it was like Cholera.

For those who remembered the days of the good will and not-so-bad representation, it was a sad time. This dark, dark period, was referred to as the Modern period, because that’s when they started chronicling the changes, and of course it was Modern back then.

The madness hailed all things strict and formal. Specification was the new correctness.

But as we approached the turn of the century for the second time in the history of the Code, there came to be a new school of thought – one that said, the specification might as well exist, but it really doesn’t matter if it’s not going to RUN.  If they didn’t run, said these Post Modernists, they aren’t codes at all. Do they even exist? How do we measure the correctness of something that exists, against something that doesn’t? Isn’t that like a cruel trial where you’re not even told what you’re being accused of?

So these reckless, shitless pimple-faced kids, who were now in their late-20s, started making up their own ‘correct answers’, or also known as ‘tests’. Of course they weren’t really correct, but they were steadfast. They said it didn’t matter whether those correct answers were really correct or not. The correctness, they argued, could only be found in the constant interplay between the code and the test.

The pure and platonic logos of the computation was pushed back to the back room. The line between the code and the correct test, between the correct code and the wrong test, and vice versa, blurred. The line between art and trash, promiscuity and chastity, vice and virtue, high-tech and low-tech, hipsters and yuppies, phone and computers and cameras and TVs and portable navigation devices, blurred.

And we find ourselves in this blurry time. Are we any closer to finding out what the correct code is? Probably not.

Not all is lost, however – I take a great relief in thinking that the era of the Black Death, UML and other horrors is now over. The era of bad music, bland building and startlingly ugly furniture is finally over.

The quest of finding out what the correctness of code is, is probably a bit more arduous than the quest of writing the correct code. But only because it’s hard, it does not mean that we get to give up. The best we can do is to question. Keep questioning, whether the code we’re writing is correct, and whether how we judge the correctness of the code is correct.

And by the end of our times, or by next Tuesday, we might catch a glimpse of the next mighty ones.