Development will become simpler

English version / Version Française ici

As a web developer and trainer for the past 15 years, I have not been spared by the “Javascript Fatigue”. My search for a “cure” to this fatigue, drove me to think about programming absurdities, and what could be the ideal programming environment.

In this introductory article, I would like to talk about my conviction: development will become simpler. Thereafter, I will prepare a series of articles describing in detail the reasons for my opinion. This will hopefully give you a glimpse of what the next development environments, as well as web programming, will look like.

My opinion is inspired by TRIZ

Imagining the future is easier if you use a method. On several occasions, I will refer to TRIZ, a Soviet method that I have been inspired by, which allows us to solve innovation problems as well as to innovate by anticipating the evolution of technologies.

TRIZ has proven its worth: for example, Samsung has been using it for years and it allowed the company to register numerous patents. In addition, this method is taught in schools in South Korea, a country that is highly innovative.

TRIZ includes multiple concepts and tools that I will refer to in my articles. I will mainly refer to the Laws of Technical Systems Evolution, and to the 9 Windows.

Development will tend towards an ideal

The first thing to know, according to the Law of Evolution N°4 — Growth of Ideality, is that programming tools, like any system, will tend towards an ideal. The ideal, in the sense of TRIZ, is defined as follows:

A system is ideal if it offers maximum benefits, without cost, and without harms.

This simple equation therefore challenges a widely held belief among many developers that if today’s tools make it possible to create applications that are more secure, more reliable, more team-oriented, more scalable, and more responsive, they should definitely be used.

These are indeed many benefits brought by modern tools and frameworks. Except that the ideal is not reached for a simple reason:

Current tools and frameworks have a cost and cause some harms

Don’t you think so? Here is a non-exhaustive list:

• confusion in the technical choices due to the multiplication of competing tools (frameworks, libraries, and tools/modules of the environments)

• lack of apps durabilities, due to these uncertain technical choices, as well as the frequent changes in syntaxes, patterns, and best practices

• need to have extensive knowledge and constant (self-)training to master all the best practices required to produce structured, secure, tested and optimized apps

• difficulty in recruiting expert and versatile developer profiles, as well as difficulty in finding jobs for developers who are not familiar with the latest tech trends

• increase in the overall production time due to the increased needed time for training, environment setup, development, optimization, debugging, testing, building, etc.

• increase in the overall production cost due to this increase in the overall production time, and because of the high salaries of the few star developers mastering all of the required techs

• loss of money when obsolete apps need to be refactored because of hype techs, hype tools, and good practices frequent shifts

This list could be extended and detailed. But we shoud simply understand that according to the TRIZ laws of evolution, these current problems will find a solution.

Shouldn’t we just learn stuff?

Some of you may think the solution is just to go ahead, and learn the latest syntaxs, patterns, tools, and frameworks. Others may say we should specialize in using one tech, taking the time it takes. Because after all, it’s part of our job. Devs need to keep up to date. Because that’s the way it is.

But asking developers to continually be trained or self-train is under-optimized. Precisely because training represents a cost in terms of time and/or money.

And it is a significant cost, even for experienced developers. Here, I wanted to refer to an article about javascript fatigue but there are too many I can’t choose. Something just doesn’t feel right.

Thus, the cost of expecting devs to continually be trained or self-train reduces ideality. It is not efficient enough. On the other hand, there is another solution that I would like to propose.

Let’s simplify dev.

It is interesting to note that the SIMPLIFICATION of development alone makes it possible to solve each of the problems above mentioned.

If the many current competing tools (frameworks, libraries, bundlers, languages, etc.) offer similar levels of flexibility and efficiency, the simplest will become the most popular, simply because it is by definition less costly in terms of efforts, training time, development time and therefore production cost.

For a while this rule was not totally true because companies and developers were orienting their choice towards tools promoted by references such as Google (Angular) or Facebook (React). Indeed, the popularity of the creators of these tools reassured companies, who saw in them the benefits of durability, reliability, and optimization. Their complexity certainly represented an investment (in terms of training in particular), but a safe investment with many benefits.

However, the AngularJS to Angular switch scandal, and the new popularity of “challengers” frameworks such as VueJS or Svelte, shows that this criterion of popularity tends not the be the most determining factor on tech choice anymore. Because we came to realize that we actually can make things just as well, but in a (little) more simple way.

Thus Simplicity little by little becomes a determining criterion because it increases ideality: allowing us to reach the same benefits, with less costs.

Simplification
= less training time and fewer competing tools
= less development time and less headaches on tech choices
= less development cost, less recruitment difficulties and increased app durability

Thus, there are many reasons to believe that with similar performances, simpler solutions will gradually replace more complicated ones.

Wrapping-up

Rather than continually learning, we should change paradigm by simplifying dev. Simplifiying solves many problems caused by current practices and habits.

However, this simplification will only be effective and useful if we maintain the same flexibility and performance offered by current tools.

Where do we start to simplify dev ?

In Devs won’t need to optimize their apps I talk about Abstraction, which is one way to simplify development.

But this question deserves to be discussed in more detail in my next articles. This one was meant to be introductory: as recommended by TRIZ, I here wanted to specify our goal, keeping in mind the ideal.

Thank you for reading me so far.