I was once a successful full-stack developer.
I had my own software house and practically single-handedly developed the modules: finance, inventory (now WMS), technical support, sales, tax, advertising agencies, and other smaller ones.
Even when I had to leave the technical side to handle sales, I needed a few programmers to keep things going.
In 2010, I decided to stop developing applications and focus solely on developing SQL routines for high-volume databases.
One of the reasons I gave up developing ERP and CRM software was because the status quo, the "established truths," and new development standards didn't seem right to me; everything was too unnecessarily complicated.
Layers and layers, folders and folders.
Things only got worse year after year, until we reached the so-called "clean architecture."
IT professionals, who were never great at saving, seem to have lost their minds. It's become the new normal to need three programmers for the backend and two for the front end, plus a designer and a QA.
Everything evolves; today, much more is required of a system than before, but these bloated teams are largely due to what Niklaus Wirth warned about several years ago. People tend to admire the complicated, when they should see complexity as a sign that something is wrong.
Current software development is flawed in so many ways that it's hard to even choose where to start.
The principles I follow are still those of 1986, when I learned to program.
The simpler, the better. The less code, the better; the faster it goes into production and consumes fewer resources, the better.
I heard many gurus saying:
I know that in MVVM you write more.
I know that TDD slows down development.
But all of this is paid for in maintenance costs and when you have to migrate to another language.
Let's break it down:
I'm about to complete 40 years in IT. I've rarely seen a company decide to change databases. When they do decide to change languages, they always rewrite everything because it's an opportunity to improve everything, even the business rules.
As for testing, a good test is one that tests everything, even the database write, preferably with data that resembles production.
If we spend an extra two hundred thousand reais to have "clean code" and apply it directly to the treasury, we'll have the money, 20 years from now, to rewrite everything from scratch, three times, simple as that.
The so-called "clean code," which constantly packs and unpacks JSON, is also more expensive in production, with 24/7 losses.
There's nothing more anti-agile than TDD, because requirements often change during development, and many of the tests written "in advance" are a complete waste of time.
Current systems development is bipolar: on one side, purists with their 50 layers, where every tiny detail becomes a workhorse, and on the other, advocates of no-code with their mediocre results.
Hypermedia-based approaches, the best-known being HTML5, aim to offer an alternative to some of this madness.
Hypermedia-based systems take a fraction of the time to build, with much less code, involve fewer technologies and fewer professionals, and also have much lower operational costs.
Instead of constantly packing and unpacking JSON, the server maintains the application state and sends UI fragments to the client.
Systems built using the HATEOAS architecture, on which hypermedia is based, consume less memory and processor on both the client and server sides, and most importantly, significantly save battery life on mobile devices.
In our case, we only have GOlang programmers, with minimal JavaScript knowledge, but there are some initiatives that only require a "backup" language like Golang, Rust, or Java.
There are challenges; the creator of HTMX regrets many of the architectural decisions he made and recently released fixi.js.
Fixi is a kind of very abridged HTMX (without the features that "aged poorly" or were replaced by new native browser APIs).
I'm not speaking out of ignorance; I've studied React, Flutter, Compose cross-platform, and others in depth.
It's almost like Chinese torture to declare the UI in Flutter; there are at least ten libraries to maintain the application's state.
Read about HTMX and fixi and draw your own conclusions.
I believe it's the architecture that companies still using Delphi or PHP have been looking for for a long time.
