Slow Coding

by Regine Heidorn, Bit-Boutique^®.

[Read this post in German]

The breathtaking speed with which some products arising from programming like software or websites seem to be developed may mislead over the fact that programming is not a fast kind of work.

Code is poetry – the slogan absorbed by WordPress – stands for one of the many movements of digital poetry coming into existence with the arrival of Zuses computers in the mid 1950s. Artificial texts result from the programmatic exchange of words as for example “Substitute each n-th noun of a text by the n-th following noun of a certain dictionary.“ – one of the experiments of Oulipo (Ouvroir de Littérature Potentielle, Working Group for Potential Literature), formed in 1960 in France, who viewed text as a fabric and fathomed the potential of aesthetics of artificial texts under laboratory conditions.

Code is poetry – in regard to the production of programming code requirements are compressing to efficient because dense production of text. Characterized by the least possible number of lines of code and characters in preferably clear nomination of either the elements of the underlying programming language and the author-chosen elements like variables and functions. The less characters and lines of code the less typewriting for the code-genesis. The more meaningful the nomination, the less semantically unambiguous, the easier the maintainability of the code. Various discussions about the structure of an ideal programming language gather around those basics.

The sense of programming is, similar to assembly line production of bulk goods, to split operations into recurring steps. Being the definition of a first criteria for the usage of programming: the operation to be programmed is anticipated as a concept which is the base for estimating expenses. Anticipating too much speed in this stage means running the risk of exploding budgets. That may result in unmanagable projects. Thus revealing another criteria for the usage of programming: the expenses of programming are measured by the defined purpose of a production step or an operation consisting of several such steps. Transformation into programming will be worth the trouble if expenses for the development of a programmed product and the integration into existing operations fall short of the expenses for operations to be substituted.

This approach is based on the assumption that the expenses of programming could be determined in advance. In fact it‘s only infrequently possible to reuse already existing software or script-libraries without verifying their applicability for the specific project-case. Programming processes contain a variety of basic requirements that are subject to permanent technical change: the chosen programming language itself is subject to change as is our everyday language. Some wellknown script-libraries or frameworks may not be maintained anymore, (new) hardware might be incompatible to some well-established programming-habits, the clients‘ usage of outdated hard- and software might prevent the usage of already established innovations in programming, maybe the hard- and software to be programmed for is already patched specifically and thus may avoid further extension. If in the latter case the documentation is incomprehensible or, worse, doesn‘t even exist, expenses are becoming incalculable. Constantly security vulnerabilities are discovered prohibiting the usage of up to then valid script-snippets. Losses in performance evolving from a certain programming-habit might force to switch to a completely new way of programming for projects being more complex.

All those conditions make up for one basic requirement of a programmer: re-reading. Rereading of own programming code for up-to-dateness and compatibility. Rereading the code of others in order to patch it with own extensions. Rereading of programming languages in order to check for the parts needed to realise individual project objectives. Rereading the code to check the criteria for security and compatibility. That‘s why programmers live in constant consciousness that their code on the date being delivered certainly is state-of-the-art but nonetheless already outdated.

“Re-reading, an activity totally against commercial and ideological habits of our society, calling us to ‘throw away‘ history as soon as consumed (…) so that we have to pass on to another story, buying a new book … re-reading is suggested here to begin, because it solely prevents the text from repetition (the ones not being able to re-read are forced to read the same (hi)story everywhere).“ (translation into English by Regine Heidorn)

Roland Barthes states in 1981.

Rereading is preventing code from repeating his history: reproduction of incompatibilities and security vulnerabilities. Cementing intricate programming and incomprehensible nomination resulting from not reflecting the use of already existing code. Adopting useless functions for the actual project that might become incalculable reasons for misfunctions. Transporting routines that might not have any function at all because they were solely coded to meet specific requirements of the previous project.

“The ones not being able to re-read are forced to read the same (hi)story everywhere“ – this is exactly what‘s happening eg to webdesigners who learned their HTML at the beginning of the 1990s and didn‘t change their habits of code-production. The result are websites based on outdated code and being incompatible to innovations such as mobile internet usage. Superfluous to tell that rereading requires time, same applies for checking the requirements for programming to establish realistic project-budget and schedule.

Code is poetry – on the contrary to prose poetry is dense – few words transport compressed meanings. Meanings also subject to change in programming languages and occasionally producing trivial redundancies. “For the master craftsperson, great code and great poetry are lean and trim, with no excess of words or other unnecessary elements.“ states Matt Ward in Smashing Magazine. Programming is a creative process demanding concentration. Slow coding thus is not a sophisticated postulate of aesthetic polemics but a semantic redundancy, a pleonasm. Which as a rhetoric figure is of ongoing importance because the breathtaking speed with which some products arising from programming like software or websites seem to be developed may mislead over the fact that programming is not a fast kind of work.