Talking to myself: Reconsidering Scalable Code Design
Tags: code, programming, design
Published: 2021-09-18 03:15:31

I’m an amateur Software Engineer interested in design and composition. I once thought to have been mostly interested in JavaScript but, the focus has shifted to design. The composition of code, the relationship between the parts supersedes the desire to work with the latest libraries, or intricate concepts… it is the impact of structure on composition and the effect on human interpretation that seduces whatever is left of my intellect.

That allure has led me to reconsider de facto resistance I offered when introduced to ideas outside of my familiarities. I just couldn’t find value in say, breaking down prose-like code into numerous units of work. How could specific processes be derived from generalizations? Specific by definition means unique, thereby already a whole unit? A thing of its own outside of other unique processes?

It didn’t help that I had been conditioned to accept that “abstractions” (as represented by breaking down large functions into smaller ones) were cause of grave confusion. That too many layers build walls upon understanding software. Why then, would design be best served in tiny pieces? More elastic when broken down into small little what? Sand grains? 

Nah, that monolith was well thought out, built from unique requirements into the essence it became.


Then, as I look in front of me, the letters A-Z above the smartboard go from one side to the other. Those, I’m told are the building blocks of written communication. They make up any word combination an English speaker can conceive. I never disagreed, in fact, there is no other way for me to jot down thoughts within my written language. It both empowers and admittedly limits me. 

Limits in the sense that each singular letter across the top of a smartboard will be the only way I’ll be able to formulate meaning. Never mind that I won’t even fathom most of all the abstractions that can be built from them. Conversely, empowering in that they are the very tools allowing my thoughts to transform from ethereal to the earthly. I suppose I’m stuck in the middle; I know what I know and outside of… I just don’t.

That is where composing very small, seemingly unimportant, utility functions come into play. Those abstractions that I rejected because of an inability to identify the possibilities that escaped me were telling me to open my mind. Much like written language with its alphabet, code of all lengths has interchangeable building blocks meant to communicate human meaning. It’s not just one way, there are many. Some with basic form like the letters on a toddler’s book, others classics of the English language.
 
From 26 English letters, the Oxford English Dictionary has managed to annotate meaning for more than 450,000 words. That’s a lot of words built on the backs of just 26 letters. What would happen, however, if the numbers of letters were decreased? Would that impact the total number of written words?  Consider this, how many words can be written with just the vowels? The letters A,E,I,O,U… suppose the permutation is 5 to the fifth power. That’s around 3K entries, and possibly most of them aren’t abstractions of an understood concept. 

What does this really have to do with programming? Well, if the goal of articulation, of written expression is achieved by building meaning from the smallest possible unit of grammar, then it reasons that the more general a function, the smaller the function, the more possibilities of being composed into say, a poem, prose, a paragraph, a book, it has. The more chances it has of being included in concepts with concrete meaning.

The reverse appears to be the opposite. That big doesn’t really lead to better, or easier to compose, to manage software. Say there is a function with some 350 lines of code. How many possibilities would that function have of being seamlessly integrated into other processes? Of being re-used elsewhere. Consider this, how compatible is a paragraph about the internal combustion engine with this article? Yet, that combustion engine article is composed from the very same building blocks as this article: letters…

That makes me think that the chances of programming any one complex function that contains unique building blocks is highly unlikely. Perhaps in isolation. At the genesis of a process, the long complex function might be arguably unique yet, soon enough those building blocks, those generalizations that are meant to be used like the letters of the alphabet, will become apparent. 

The next step then is to give meaning to those building blocks, to those abstractions. I used to believe that abstractions were a bad thing because they obfuscated meaning. Then, upon reading a collection of letters, it became clear that X amount of letters combined to form meaning didn’t prevent me from understand a complex concept. Their composition didn’t confuse nor make me question why X word became an abstraction, why it came to mean a much larger concept than each of the letters in isolation. No! That abstraction brought meaning, it made words… palpable, relatable, interchangeable… enlightening.

As an example, the noun “programming” is an abstraction of a concept. It gives meaning, not only to the composition of the letters “p,r,o,g,r,a,m,i,n,g” but, also to the context in which the noun is used.  It creates a picture of all the possibilities in which the word can be used. I don’t question the validity of the letters “p,r,o,g,r,a,m,i,n,g” as an abstraction of a concept. But, how I questioned building abstractions is still fresh in my mind. I spent too much time closed-in because what I knew of programming kept my from seeing the rest of the vocabulary to enrich my expressions... I have never really built anything unique. I have built unique concepts from the same fabric. 

Individually, small functions aren’t really all that useful. However, when composed with one another like letters on a book, they can express it all. Oh how it haunts me that it took this long to see letters in code, the value of the simplest form that too can build innumerable process from just 26 letters, like the alphabet. 

Over my shoulder stands each process that was re-invented again and again. Each new use case was accompanied by the same ideology. Believing each to be a unique something. Meanwhile, my codebase grew into this prose-like collection of abstract thoughts as code. In reality, a collection of run-on sentences entangled into nearly indecipherable cohesion that if touched incorrectly, it would crumble. 

Over the years, the alphabet continued their silently press against the tip of my fingers from the keyboard. Had I kept my fingers against them just a little longer a-way-long-back-ago, I’m sure it would have told me to consider that back in grade-school the building blocks of written communication were introduced as the a,b,cs... 

Build your blocks.

It really was challenging to see.