Originally written in 2016.
Obsolescence
Obsolescence. A word that bothers me tremendously yet fills me with hope. Allow me to take a long winding road here.
The notion that today’s tech can solve tomorrow’s problems is as fallacious as it gets. In fact, I’d argue that the moment the seed of an architecture takes shape in an architect’s mind, it is outdated because that architecture if gets built is busy building a relic of the past. In fact, it’d be much easier to wait and see what the next big wave is around the corner to adopt. And, then all the system problems will be solved. In fact, you may not need to solve it — which is even better. Something better will come along and all the past sins will be washed away.
It is said if you need only one instruction for the CPU, it is “if not equal to” (abbreviated as JNZ or Jump if Not Zero) and will be familiar to the electronics folks as the quintessential NAND gate. A very counterintuitive instruction — imagine reading code written using only that instruction. Whatever you do, there is a JUMP to a different section of code. And, those jumps are what our brains can’t effectively keep track of. It is a marvel that we can hold a sustained thought — let alone keep track of a chain of thought where there are further rules that govern how one thought should lead to another. Be it arithmetic or maths or even programs.
Code creation uses symbolism from a human language (English like) and adds a layer of semantics — then you need to read it left to right, one character at a time, parse, tokenize, build a mental model of a compiler (a set of rules defined by a random human being — most folks don’t even know the creator or the maintainer of their favorite programming language let alone the tool chain creator). This model is then provided as input to another program. The resultant output is then given as input to run to another program (the OS or the virtual machine) and if the behavior doesn’t match expectations, one attaches another program (a debugger) to try and model another set of expectations. All in all — quite an impressive feat.
Think of the training we’ve been getting for this since school — solving equations in school. We always knew that left side had to equal right side. There were symbols for values (numerals and the decimal point), symbols for representations — mixed fractions, vulgar fractions, recurring fractions, negative numbers, complex numbers, square root, power, exponentiation. There were symbols for logic and even often used English terms like ergo (therefore), implied by (since), implies, equality, inequality etc. And manipulating and juxtaposing symbols or patterns of ink on paper leads to it if done in the way expected by the teacher or the text book. Compliance results in getting another marking of ink on paper viz. a 5/5 or a 8/10.
So we see — there’s quite a bit of “Softness” or non-concrete-ness in the way we’ve reached here.
So I’ve established that you are an amazingly capable individual. And, I am sure you are nodding as well. Then tell me why would you not refactor that damned piece of code that you’ve been sitting on for months and years now to make it faster, better, neater, maintainable, cheaper etc.