Churn

Have you heard about the guy who said goodbye to the OOP?

Oh no. One more? What did he say?

He described all the promises of OOP, and how none of them actually were fulfilled, and that all the possibilities of OOP are more expensive than they really are, and functional programming is better, and ...

Oh. Yes, I heard all this before ...

Thus, the OOP finally died, and we can move on.

Move on to what?

What are you doing? To the next technological breakthrough, of course!

And to this ... And what's in our turn?

I don’t know, I’m very attracted to the idea of ​​micro-services; and I am very interested in Elixr; and I heard React is really cool; and ...

Yes. Yes. Churn. You fell into the butter churn.

What? What do you mean by that? Now is an exciting time.

As for me, rather depressing.

Why? New technologies are emerging every week! We are climbing higher and higher heights.

Chu! Everything that we really do, reinvent the wheel, again and again. And we waste time and tremendous effort on this.

Oh, come on! We create PROGRESS.

Progress. Indeed? This is not what I see.

Well, what do you see?

I see wastefulness. Massive, innumerable losses of time and money. Prodigal multiplied by profligacy and multiplied by more profligacy.

How can you say that?

Well, consider at least this question with OOP. OOP is not dead. OOP has never been alive. OOP is a technique, a good technique. To say that it is dead is like saying that a good screwdriver is dead. Saying goodbye to OOP is like saying goodbye to a good screwdriver. This is a waste!

But functional programming is better!

I'm sorry, but it's like saying that a hammer is better than a screwdriver. Functional programming is not "better" than object-oriented programming. Functional programming is a very good method that can be used in conjunction with object-oriented programming.

This is not what I heard. I heard that they are mutually exclusive.

No, of course. They are aimed at solving orthogonal problems. Problems that are present in all projects.
Look, there are people who think that software development is a linear progress. Type we climb one step of the stairs again and again, and each "new" step is better than the previous "old". But that doesn't work like that.

And how does this work your way?

Software progress follows a logarithmic growth curve. In the early years, progress was dramatic and impressive. In subsequent years, progress has become much more gradual. Currently, there is almost no progress.
Look: the assembler was much better than the machine code. Fortran was much better than an assembler. C was significantly better than Fortran. C ++ is probably better than C. Java was an improvement over C ++. Ruby is probably a little better than Java.
The cascade model (waterfall) was much better than nothing. Agile was better than a waterfall. Lean was a little better than Agile. Kanban may have been something of an improvement.
Every year, although we make great efforts, we are making less progress than a year earlier. Because every year we become closer and closer to the asymptote.

Asymptote?! Do you think there is an upper limit to software development technologies?

Sure. Moreover, I think that we are now so close to this limit that any further effort is fruitless. We have already passed the line of falling efficiency.

What? That sounds ridiculous! And depressing!

I understand. But this is because we are accustomed to rapid growth. Those were the heady days, and we want them back. But they are gone, and we must acknowledge the fact that we are wasting time and effort on a massive scale, trying to recreate them.

But if we do not push the future, we will never create it!

Believe me, I definitely want us pushing the future. But this is not what we do. We just yearn for the past.

So what future should we aim for?

To productive. To a future that is not subject to the wasteful churn.

What does "wasteful" mean in this context?

Have you ever used IntelliJ or Eclipse for Java programming?

Of course.

These are incredibly powerful tools. An experienced specialist can be highly productive with these tools. Refactoring! Representation! Facilities! My God, these tools are impressive!
However, each time a new language arises, we discard powerful tools to move on to the NEXT NEW THING. And the tools for a new programming language look like the standard of living in third world countries. God, often there is not even a banal "rename" refactoring!
It takes time to create a decent set of tools. If we continue to switch from one language to another, we will never provide them with reliable tools.

But new languages ​​are better.

C'mon! They are different, but they are not better, at least not so much better, to justify the return of the set of tools back to the Stone Age.
And think about the cost of training to adapt the new language. Think how much it costs organizations to use 84 different languages ​​just because programmers are addicted to new brilliant things every two weeks.

New shiny things? It sounds like a shame, is not it?

I believe that, but often it all comes down to this. New languages ​​are no better, they are just brilliant. And the search for a golden fleece in the form of a new language, or a new framework, or a new paradigm, or a new process has reached a point when it becomes unprofessional.

Unprofessional?

Yes! This is unprofessional. We need to realize that we are rested in the asymptote. It's time to stop the wasteful churning of languages ​​and frameworks, as well as paradigms and processes.
It's time to start working.
We need to choose a language, or two, or three. A small set of simple frameworks. And then build our tools. To crystallize our processes. And become true professionals.