Stray Of (Software) Development
It’s been itching me for a long time now, I fail to resolve the feeling that not everything is as it should be; deceived by the noble reflection of the guilds. Finally, many years later, the feeling becomes a thought, and the words find their way.
Software development is chained, it doesn’t go much further; and that is caused by one thing.
Modern software development makes simple tasks difficult, in order to make trivial ones even easier.
Twenty years of almost daily typing of code are woven into this thought. It should not be dismissed lightly.
Where To Start?
The programming languages we mostly use are still general in purpose. Each for itself is a ‘language for all’, reaching the exaggerated-to-nonsense concepts of OOP at best. Programming languages know how to require unnatural, too extensive precision in order to, for example, define a variable type, and are easily lost in the more demanding intention of controlling the code. There are only compile-time and run-time phases (phase distinction), imposed by the method of obtaining executable code, not by necessity. We are still struggling to separate exceptions from mistakes. We scare beginners with patterns, and we stopped writing algorithms. What we learn has not changed for decades, it’s just got a new syntax.
What would be the evolution of programming languages? The end of their existence. Generalization is generalizing, unification of actors, reduction of diversity and characteristics. We need new, domain languages, each of which solves specific problems and can be mixed. We need languages that we can write and refine ourselves, change grammar and syntax on the go. We need languages that have solved memory management, synchronization, and everything that influences the abstraction of the domain being modeled: as great deviation from machine thinking as possible.
And the frameworks! Everything that we fail with programming languages, we solve through programming libraries. Frameworks are actually platforms: you do not program in a framework, but in a platform, from which there is no way out once adopted. The framework should only provide a… framework in which the programmer keeps solving trivial things as he pleases; the platform gives you a solution to trivial things, but also molds in how you do everything else. Do we need magic to bind backhand components? Do we need a magical frontend that recognizes all the changes on its own? The correct framework limits the use to the solutions it offers, thus, by design, not allowing the developer to misuse it. Imagine such an API that explains itself, where the framework takes you with its syntax to the next step, not StackOverflow! The platform design is determined by the same sluggishness that demands to be solved as soon as possible and move on, or by undercooked concepts that do not solve the cause, but the consequence. Corporations can play because they have followers, thus allowing incremental tectonic changes to their platforms. To mutually cooperate, that they don’t know. Software platforms are becoming a means of consumerism, turning developers into consumers, and attracting new ones with colorful royalties of easy solution to the trivial.
The world of programming is experiencing a crisis of hyperproduction. A way to attract a programmer is to impose compulsive needs on him. And those needs must be homogeneous, not individual. Ergo, we do not solve difficult tasks.
Inherence?
There’s that urban programming proverb that says a good programmer is a lazy programmer. He hates doing repetitive work, thus finding a way to program them instead.
I accepted it for a long time, until recently - I learned that it’s not quite like that. Although the proposition is in place, it turns out that the lazy programmer is also lazy to program the solution. At least that’s my experience - I admit, I’ve done it countless times myself. A barely sufficient solution is as dangerous as a pre-engineered one.
The right approach should be different: laziness shouldn’t be the one indicating refactoring, but analysis. And it is just the opposite of laziness; it requires the active involvement of cognitive skills and knowledge.
The topic here is not laziness, but attitude. I don’t want programming code to be determined by feeling, but by thinking. I don’t want software development to be determined by solutions to trivial tasks, but by the progression of ideas for solving difficult ones.
In the end, I have to ask myself: is the situation like this because it’s enough for us?
Because then we’re in trouble. And if it’s still OK for you… then nothing.