Writing Code

This blog was written quote a number of years ago (2013-2014), but I hadn’t published it. I got around to tidying it up a little. Enjoy.

As software developers we write code. ¬†The code is intended to represent what a computer should do for a business or person. ¬†Recently, I was caught in a scenario to make me think – all the code I was writing for a project, was representing what a computer should do for a computer, not for a business nor a person. That didn’t feel right to me, the business was still my client, not the computer. Warning signs flashed unanswered in my brain – I could picture the real customer would soon ask why the system was behaving in a slightly different way then they had prescribed.

I then thought about that term ‘writing code’¬†and wondered what it really means,¬†centring¬†around the following questions:

  • Who do we write code for?
  • Why do we write in code?
  • What do we have to hide that requires us to write in code in the first place?

Who do we write code for?

Ourselves – It is the gratification of building something that makes someone¬†else’s¬†life easier or more productive, and on a personal level, boosts our ego’s because its presented a technical challenge or two we’ve successfully address. ¬†This reasserts our ‘Id‘, that I’m smart and up to future challenges which ties into further opportunities later in life.

Businesses – They need an automated workforce. ¬†Automated workforces cost $0.00 to run, energy and maintenance costs excluded, and take no time off. ¬†They are the best kind of employee. ¬†However, they lack autonomy, so at least you are safe from losing your ’employee of the month’ award to a robot. Because of this, we developers are kept in employment as we are the trainers of this workforce to help them perform tasks they cannot accomplish out of the box.

Family / Household РWe exchange coding services in return for money to support our family and loved ones.  This works out well because businesses have the $$$ we need to exchange for food to sustain our lives.  In many cases, where we need $, we get paid $$ and so many programmers can enjoy a decent quality of life.

Why do we write in code?

It would first be wise to get a few definitions of code. Over to you define:google

  • a set of rules or principles or laws (especially written ones)
  • attach a code to; “Code the pieces with numbers so that you can identify them later”
  • a coding system used for transmitting messages requiring brevity or secrecy
  • convert ordinary language into code; “We should encode the message for security reasons”

and a computing perspective:

In cryptography, a code is a method used to transform a message into an obscured form, preventing those who do not possess special information, or key, required to apply the transform from understanding what is actually transmitted. …http://en.wikipedia.org/wiki/Code_(cryptography)


In computer science, source code (commonly just source or code) is any collection of statements or declarations written in some human-readable computer programming language. Source code is the mechanism most often used by programmers to specify the actions to be performed by a computer. http://en.wikipedia.org/wiki/Code_(computer_programming)

These two definitions are interesting and a bit¬†contradictory. ¬†On one hand, we are coding information to obscure it and prevent it from falling into the wrong hands. ¬†On the other hand, we are using it as a way to understand the actions of a dialog we don’t interpret as speedily as our native tongue – unless machine language¬†is your native tongue.

Could one kind of coding, for all the positive reasons outlined above, be turned into the cryptic un-malleable kind unintentionally?  

Why did we need to introduce code? Anyone who knows about old school computers that took whole rooms in university labs back in the day remember punch cards.  It was a way of coding, the arguably human readable form that allowed the machine to do what we wanted.  Presumably this method was fraught with errors and the odd bug would creep in (sometimes literally) resulting in wasted time and effort.

So we decided to improve the code used by introducing new languages and tools, and sans a history lesson, have tried to encapsulate the layers of code into more human readable abstractions that match what their masters want.

Of course it would be hard to not speak about Domain Specific Languages (DSLs) here and the benefits and virtues of tailoring a language to a specific domain that is spoken by the people that we write the code for.  The idea here is that if we speak in the language of the customers, we can communicate ideas faster, highlight and deal with inconsistencies sooner, because the language of our automated workforce matches more closely the language of their masters.

But we have a problem. ¬†DSLs are only relatively new. ¬†Coding has been for much of the time, writing to some level of abstraction just above the punchcards. Trying to get the Abstract Syntax Tree’s to process the data in the right way to put it in front of a calculating machine and to produce the right data out. ¬†The abstractions (newer languages) are neat, but we still have to consider that lower level work. ¬†Databases, networks, threads, cpu caches. We don’t escape it. ¬†We have to deal with it along with the original concerns the automaton we are building must handle. ¬†We have to add more punchcard code in order to make the automaton code work.

And so, in working with code, there is the potential to go from the computer science definition to the cryptography one almost by accident. ¬†Even with todays languages, the process of coding is verbose, mostly due to the nature of the ‘punchcard coding’ we do in order to move bits around. The production of a data transforming, processing machine is quite different to the inputs and outputs that machine handles. ¬†Therein lies the problem, the code becomes¬†unmaintainable¬†because it is far removed from the intended use of the product it finally lives in, its been tainted with a different language.

What do we have to hide?

Well surely there would have to be some benefits to coding by the letter. ¬†Here are some consequences, I’ll let you decide if they are worth the gains we receive:-

Secret Sauce – we may come up with something smart and clever that no-one else can do nearly as well. ¬†And because of this, code is a godsend. ¬†If someone does steal the code, it is somewhat obfuscated¬†by its very nature of being full of indirection. ¬†They’ll have to spend time analysing it without someone to guide them through the hairy hacks before they can think about using it.

Our niche’s – If we write code, until we explain it to someone else, we are the sole masters of it. ¬†It’s easy to own some code and get praise for it, because then you are the conduit and enabler for future expansion. ¬†You are kept needed until you relinquish control.

Keep the non-experts out РSpeaking in a language with terms that are the lingua franca of an industry, and then having concepts that take some level of expertise to understand means that there is a force-field, keeping those who can do the most damage away from changing something to break it.  This has a shoot yourself in the foot approach РUnfortunately in programming, since codes are built up from other codes, someone can understand Java, but not a design pattern implemented within, can miss its original intent and make changes that are unintended and make the code equally as hard to read.

Hurdle Buffer –¬†Lets face it, when there are layers and indirection, pointing the finger at something/someone is harder. ¬†Layers and indirection also buy us time. ¬†Generally we find these distracting, but if you are in a high pressure ‘want it yesterday’ environment then putting in these artificial indirection layers allows you to see what’s coming as the requestor pushes their request through the indirection channels. ¬†Note, this is probably an organisational smell, the appeal of a hurdle buffer is¬†probably because you are navigating some other part of the organisations hurdle buffer, in place for much of the same reasons.

So why keep doing it?

Should we dis-associate the computer code from the business code?  If it stops ups being cryptic then absolutely.

I can only think that the past was littered with systems that performed poorly, and the solutions were to involve layers of abstraction that catered to the needs of this.

None of the previous sections ‘values’ are reputable traits by any means, so the more efforts we make to separate our business code from our computer operational one, should be welcomed by all sides.


Leave a Reply