How to keep the code coherent

Photo by James Wheeler on Unsplash

The power of coherence

For example, it is the usual goal of refactoring to change the code to a more compact form, where repeated code has been “factored out”. While the end result is the same, I’d like to argue for a more systematic approach, where such refactorings are needed much less frequently: When the code is coherent, it means, it is being born that way, from the beginning!

Back to Earth

I can hear more rumblings like “don’t follow DRY too strictly”, KISS, and YAGNI. However, this only reflects how software developers, especially those without computer science or math background, reinvent mathematical concepts as they gather experience over the years. Experienced developers still have that voice inside, telling them “this need that thing I did in the project X… let me recall… it had some associative operation, and then it needed some empty element… and then we can concatenate them”. Their brain is thus having a notion of a monoid we use as an example here, without realizing it. And it is but one example. There are more “patterns” like that stored in the software developers brains as they gather experience.

What is it for humans in it?

Human reality is much less coherent, and that is why we give up so often to find a better root for everything we want our computer to do for us and our users. Layers of existing software skew our picture of the software world even more. Leaking abstractions are unavoidable. So how can we still write software coherently given all this heritage of our prior solutions and users’ mental models of them? Here the user’s mental model being aligned with that of software is understood as a prerequisite of any good user experience with possible exception of games.

To the point

Developing software goes farther and farther from it’s mathematical roots, and in the name of practicality it is common to assume quality software requires extra efforts and experienced developers. What is probably not understood is that experienced developers are mathematicians, who rediscovered what has been already known for quite some time. There is also no incentive to learn more fundamental approach to creating software because “everyone can code”, “we do not need all that abstract garbage in our front-end development”, etc, etc. Educating oneself in abstraction-making, learning from fields where abstractions are used fluently is the only road to become the master quicker. This requires reflection on the ways one thinks. To benefit from “abstract ideas” one needs to learn to see the connections of those abstract concepts and the real world. I am pretty sure having these abilities would not harm anyone. The most obvious winners are those, who learned to reflect on the ways they think from the childhood. Abstract — concrete bridge can be discovered then, and become a very sharp tool by the age one goes to the university, because having the bridge makes studying at school much easier.

In addition

This article was almost ready when I understood one fundamental difference in programmers’ approaches to building software.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store