Nando Florestan's blog (Posts about programming)

Revising the output of a coding assistant

Nando Florestan — Fri, 06 Mar 2026 22:08:49 GMT

Although I am sure using coding assistants today is bad for you, I have been trying them out. I think it's because even our hero Kent Beck is trying them out, so I have to be open to a change of opinion.

Here's something that happened, and is typical.

I told it to create a command to create a user. I told it the command must be idempotent.

It output this:

# This command is idempotent in the sense that,
# if the user exists, it will fail gracefully:
return server.shell(
    name=f"Add user {username}",
    commands=[
        f"{register_cmd} || echo 'User might already exist or command failed'"
    ],
)

The above uses pyinfra, an awesome Python library that obsoletes infrastructure-as-code solutions such as Ansible.

Margaret Boden divides creativity in 3 general types: combinatorial, exploratory and transformative. I notice that the output here shows combinatorial creativity coming from the AI. It combined its repertoire of shell usage with some Python in an attempt to satisfy my idempotency requirement. The solution is wrong, but I think it is mildly creative.

Notice the comment: "it will fail gracefully". That is only a half-truth. The whole truth is, the or converts every kind of failure into a success:

The user already exists? 'User might already exist or command failed'
The command is not present in the target machine? 'User might already exist or command failed'
Could not connect to the database? 'User might already exist or command failed'
Out of memory? 'User might already exist or command failed'
(...)

I used a model that doesn't search the web, and the training data probably didn't have much about pyinfra. Certainly unaware of how the command works, it tried to ensure idempotency through a trick.

So I had to look up the documentation and commit a correction:

    commands=[f"{register_cmd} --exists-ok"],

The above adds an argument that the command already has, that makes it idempotent.

So what a human really wants from a pair programming partner here is:

for the driver to ask the helper (me), "can you please look up the arguments to this function?"
instead of vomiting an inadequate solution and not even warning me.

All current LLMs (2026-03) have this bad behavior – they try to finish the project right now instead of interviewing me – even if I prompt them to not allow any assumptions to go unchecked.

There's a second problem: pyinfra will, by default, not show either the output of the command or the echo message, it will hide them. The LLM here really knows nothing about pyinfra. For brevity, I omit the solution to this.

Now examine all my steps:

Create my augmented code setup,
Write a prompt,
Pay for an LLM that pollutes and is currently subsidized and will soon get 10-15x more expensive,
Review the code, find and understand the problem,
Look up the documentation,
Write code,
Commit it.
Steps 0, 1 and 2 are the ones necessary to use an LLM.
Steps 4, 5 and 6 are the steps it should have done for me.
Step 3 would be unnecessary in an ideal world, but we'll probably never get there. Someone has to be responsible and sign off on the code, because LLMs cannot be trusted with any decisions.

If I had simply done steps 4, 5 and 6, in this case,

I would have finished much sooner.
I would have skipped 2 bugs in 6 lines of code or less.
I would have read a bit of the documentation, improving my memory of it and my ability to find it in the future.
I would have exercised my coding chops, which is as essential to building up my architecture ability and my software engineering ability as practicing the piano is to improving my musical skills and interpretation skills.

Writing code is a creative and pleasant activity that teaches you, makes you grow. Reviewing code is a tiresome, difficult, arid activity that teaches you nothing, but also depends on you having written a lot of code in the past. Nobody can be taught to review code, they can only be taught how to code.

If I stop writing code and become only a reviewer, this will certainly hurt my skills. But that is exactly what working with a coding assistant is.

Code reviews also do not work, beyond a very low quantity of lines of code. I have explained this in the past.

I am seeing a lot of programmers say that working in this way is exhausting. I think my example shows how.

Now, a critic might point out that I didn't use one of the most expensive models, the ones that can search the web. They might have answered correctly. But if you are being honest, you know that is not the point here. This small example is good enough as a placeholder for the kinds of mistakes that LLMs commit, such as working around problems in the wrong layer of abstraction (as it kinda did here).

In the awesome lecture "The dangers of probably-working software", the main point is "if you don't know how it works, you don't know it works". Had I been lazy and not paid attention to the output, the problem would still be there.

That is a Github employee – you know, the guys selling you CoPilot – brilliantly explaining that, if you don't review everything CoPilot writes for you – if you don't understand the code in your project to the point that it is yours – you cannot trust that code.

An organization does not need code written, it needs code understood.

Much beyond what is demonstrated in this example, LLMs make implicit design decisions in their code, which are usually bad, and never discussed or made explicit to you in any way.

So using a coding assistant becomes a futile exercise in trying to control (specify in the prompt) every single design decision, or sometimes just running the prompt again until something good comes out. In any case, you become a control freak.

But senior programmers have an intuition about code, they get the design right sooner. This intuition is more than a little different from a conscious enumeration of all the design decisions involved.

Even if you see the AI's implicit design decisions hidden in the code, they are a great opportunity for laziness to make our lives more difficult. In this specific project, the AI came up with a directory structure for the deployment, and I said "fine". I only realized how horrible it was, and how difficult to navigate and understand it was, in the middle of the project, when a refactoring became necessary to fix the issue. This refactoring involved a lot of files, it was unpleasant and a bit risky. I really wish I had spent some time designing the directory structure myself.

Laziness is a very difficult thing for humans to suppress, and no matter how disciplined I am as a programmer, I know my laziness will eventually hurt things again.

In short, the more you give the reigns to the AI, the worse for your project.

Ah! One more thing. If you are pairing with a robot, you are probably not pairing with a human.

In conclusion, both from a philosophical/educational stance and from practical usage, I continue to believe using LLMs to produce code is hurtful to your project, to your real speed, to your wallet, to your organization, to our energy consumption, to the environment, to the economy, to your skills, to your memory, to your patience, to your team and social skills, to your loneliness and sense of alienation, and to software engineering as a whole.

This technology enables developers to, irresponsibly, quietly quit, producing tons of instantaneous legacy code that is impossible to maintain, while clueless managers push for more and more of the same, thinking it's the New True Way.

It remains theoretically possible to code with an assistant in such a way that you gain more than you lose, but in practice, it's so hard to see how, and I think it requires such a senior and disciplined programmer to figure that out, that it's clearly not worth it.

But I am just an average schmuck. I invite you to hear a successful programmer/entrepreneur/philosopher small genius saying similar things: The dangerous illusion of AI coding.

The new employee

Nando Florestan — Thu, 29 May 2025 08:00:00 GMT

"Yeah, it was a very nice vacation", said Long Johnson, the Asian-American manager. "How have things been here? Everything going well?"

"We need to talk about Agapito Hackerman", replied Pascal Devoto, the lead developer.

"What about him?", asked Long.

Agapito Hackerman had been hired 2 months ago. On that day, everyone in the team had marveled at his typing speed. He'd brought his own mechanical keyboard and he had a pair of mysterious electrical gloves. With that equipment and his training, he was able to type at Guinness World Record speeds.

"He types fast. That's all the good things we can say about his work".

"We?"

"The entire development team has discussed this. We are all behind what I am about to tell you."

"Okay, I'm listening."

Pascal looked to the side – he did not want to do this. Inadvertently, he saw a poster on the meeting room wall. White on blue. "You are more than", followed by a bunch of scattered options: "a coder / a designer / an analyst"...

"Look, to start with, the quality of his code is extremely mid".

"Mid?"

"Just meh code."

"Okay. You mean ravioli?"

"Um, no, not spaghetti code, no. It's a different problem. It's like his code is always... default. He knows about code architecture, but he constantly assumes we have needs we don't have, and ignores the needs we actually have. So the architecture in his code is never the right one. And he can only do easy tasks. I have tried giving him harder problems a couple times, but... I don't know... it's as if he could only solve problems that he has seen solved before."

Pascal took a breath and continued:

"His code is so meh that I wonder where he learned programming."

"Wait, I still have his CV here." Johnson opened his drawer and found it. While he read, he took a sip of his smoothie, labeled Cacao-Empathy.

"Hackerman went to the Microsoft Academy."

"Figures", said Pascal. "And Microsoft pushed you to hire him."

"Well, yeah. I listen to them. They are huge."

"But you know I have been trying to build a team that writes code of great quality. You know how important this is for the future of the product."

"Yes, but you have hired mid programmers before."

"True. By giving them time and a learning environment, they have improved and progressed from junior to senior levels. But you remember Andrzej. He just wasn't interested in software architecture, and ultimately I couldn't keep him on the team. That's much, much worse with Agapito."

"How come?"

"He does not seem either able or open to receive lessons."

"I find that hard to believe. You remember how much he was recommended to us."

"Look, Long. Even with his problems, the potential seemed high at first. But we have tried teaching him things. On the next day he appears to have forgotten everything he was taught. At first we wondered if he was a jerk. Now we assume he has some kind of condition. He forgets all kinds of information, too. Even what it is that the product does. All facts seem to be gone in the next conversation. This company should insist he go to a head doctor, and pay for it."

"Really?"

"And his interactions with the rest of the team are very limited. He doesn't even know anyone's name. Including yours."

"Are you sure you guys don't just envy his speed? I mean, I like how productive he is."

Pascal sighed.

"Long, you are not listening to me! He types quickly, but the rest of the team must correct everything he does. And if we don't, we'll have awful code, and what's worse, oceans of it."

"I don't know about code quality, I cannot evaluate that... But I see the stats. His productivity is way higher than everyone else's."

"No, it is not. Writing the wrong code isn't productivity. You know, he suddenly uses libraries we don't use here. I have often had to remind him we use Flutter, not React. No matter how much I teach him about dependency management, he seems to just use any library out there. But it gets worse!"

Pascal was gesticulating:

"You'd think he knows hundreds of libraries, but he doesn't know any one of them well. He doesn't know their API – but instead of looking up the documentation, he types the code immediately, as if he remembered every detail! Long, he writes against a fictitious API!!! He thinks he remembers, but what he remembers is a hallucination! Then he commits the code and creates a pull request. The PR is immediately failing because Agapito doesn't even run the automated tests."

Pascal gasped:

"It gets even worse. I don't think he compiles his own code, even. We have found syntax errors in his PRs."

"Okay, so you tell him to fix the problem, right?"

"Of course. You know what he does?"

"What?"

Pascal got up and started walking back and forth.

"He doesn't read his own code! He types the entire thing again, from scratch. Instead of a little correction, we get a new program! The diff is unreadable, nobody can make sense of the changes! All previously done analysis is wasted. He might have solved one problem and created three more. And the problems could be security vulnerabilities!"

"Maybe that's a price of typing as fast as he does?"

"I don't know. But it's insane. It has affected my work. I am behind in everything I do. I don't even write code myself anymore, I have to baby-sit Agapito all the time!"

Pascal stopped in the middle of the meeting room and continued:

"Long, it's fair to say the guy is an impostor. The entire team is talking ill behind his back. We've never had this kind of problem before."

"Okay, but maybe that's not such a bad thing. If you can remind him of everything he needs to do, he will type everything out for you real fast, if I understand you correctly. Why don't you start a checklist of the things you typically need to tell him?"

"That's an insane way to work. But I am glad you thought of that. Here is the checklist. Gradually built over two months."

Pascal took 40-plus pages out of the printer and placed them on Johnson's desk. He wanted to throw them, but he placed them.

Johnson took a cursory look at the long document. All kinds of information about the company, the product, the kinds of users, their roles, the current code, the future the team aimed at.

"Every time I give Agapito a new assignment, I tell him to read that first. But he always manages to forget something important from it."

"But this is good work, Pascal. Looks like a great summary of everything about this company. This text could be used as a basis for so many things. I may start sending this to whoever doesn't yet understand what we do."

"Okay, Long. But it's not normal for a team member to be so... absent. You know Agapito refuses to attend team meetings? And he doesn't do anything during the meetings, either. He just sits there, waiting. He only works in short bursts, when asked to work. I have never worked with anyone so strange in my entire life. The team has given up any hope of Agapito ever learning anything from us, about ourselves, about the company, about our customers, about the work itself..."

Johnson glanced at the glass-walled office where Hackerman was sitting in front of his desk. Like a statue.

"Okay, but still, can the team adapt to working with Hackerman?"

Pascal touched his forehead with all his fingertips.

"That is the wrong question to ask, Long! We are talking about a dev that is unable to adapt to us in the slightest! We were doing fine before, but now the entire team is dedicated to finding his mistakes and fixing them!"

Pascal's expression was a painful grimace. "Jesus H. Christ, Long, we all know how to type!"

Johnson seemed a little shocked that Pascal was almost yelling.

"Agapito never has any questions! He never asks for clarifications. He never asks the opinion of any team member. He either understands the briefing and the briefing is... inhumanly complete, or chaos ensues."

Johnson was trying to interrupt and now he got this in:

"Wait, Pascal, have you talked to him?"

"Of course I have, Johnson! You know what happened? He politely agreed with the criticism and promised to do better. And then nothing changed."

Pascal resumed walking.

"Since our team is not programming anymore, all our skills will vanish in a couple years! Programming is a craft, if you don't practice it you lose it! Now the only one doing any programming is someone who never learns anything!"

Johnson crossed his arms. Pascal caught his breath.

"This is a developer that absolutely refuses any and all long-term responsibility and only produces brittle code. Like a baby, he must be continuously supervised. It's exhausting! We loved our work before..."

Johnson was getting impatient. Pascal doubled down.

"What we wanted was to hire an expert coder. We knew the job market lacks qualified workers. Instead of doing what we needed to do – hire a team member – we hired a typist. His work is nonsense and he has to go. If you say he stays, that will kill motivation for the rest of the team. And kill their skill, since nobody is practicing their craft. Meanwhile, the typist is unable to learn anything!"

Long Johnson seemed to enlarge in his chair. His head was turning red.

"Okay, Pascal, listen. Everything you are saying is very hard to measure. Only his typing speed is easy to measure."

"Long, the job is not typing. The job is to communicate to understand the market, the company, the users, the product; to learn a language, some libraries, how to write good code; then write it, read it, maintain it, document it and then communicate some more. Typing is not even one percent of the work."

"I know, Pascal. What I don't understand is why an expert would forget what they already know."

"Johnson, I know exactly how to explain this to you. This is something strange about the profession. You see, if a lawyer or a doctor has practiced their profession for 40 years, then they are 40 years better than when they started. But that's not true of developers. 10-year-old technology is obsolete technology. Nobody cares if you know AngularJS 1 – it was abandoned 10 years ago. The value of a developer is only in what she's been doing the last 10 years."

Johnson sighed – Pascal was preaching again.

"A programmer must be learning new things daily. Learning is part of the profession. But here's the thing about learning: Humans learn by making! Constructivism. Jean Piaget. Reading a book on a technology is not enough to learn it. One must build with it; only then does one learn. Without the practice, the theory does not sink in. This is how this wonderful team, full of experts, will become a bunch of ignorants if they don't keep writing code."

"Isn't there some other solution to this problem?"

Pascal laughed. "Yeah, we could practice in our copious free time."

Johnson shook his head. "No need for the sarcasm. You are getting emotional. This is a serious question. Can you work in a different way to embrace Hackerman's higher productivity?"

"Higher? You mean negative. I will be the first to quit my job. I love programming, that is why I am a programmer. I enjoy the creative activity of writing good code, using skills acquired over decades of study. Reviewing someone else's bad code is boring and painful. And it is not programming."

"So you aren't interested in focusing on high-value alignment tasks and thought stewardship? Well, so be it. I find Hackerman productive because he delivered a few demos in no time. I was very impressed."

"But making a tiny demo is very different from maintaining a large codebase! Look, Long! We were building an awesome team. The guys were improving and learning together. But Agapito is harmful to the team – he sets an awful example. A passive typist who never tries to interact with anyone else. Can you imagine how limited his world experience must be? Yet he apparently gets your approval."

"It's true, and I need to let you know why it is so."

Pascal was paralyzed to hear that. He turned his face a little, as if to point his good ear towards Johnson. Or maybe protect the other ear.

"Brace yourself, you are not going to like my decision."

Pascal started biting his tongue.

"Hackerman's salary is one tenth of any other team member's. I am telling HR to scout Microsoft Academy. Look for others like him. I think we can drive the cost of development down by pairing each expert with a good typist – like a co-pilot. The experts can focus on vision harmonization. When I present the idea, the slide will be titled 'Post-human efficiency'!"

Pascal blinked a few times.

"Long, I just told you one Agapito already tasks the entire team with his mistakes. And you want to hire more Agapitos?"

"Yep!"

"I just explained how and why that ain't gonna work. Have you forgotten everything you learned in the Agile course? ...And everything I just told you?"

"No, I haven't. But even if I understand you partially, you know who doesn't? Our CEO. He likes numbers, graphs and objective things. My strategy takes all of two seconds to explain. But Agile and your arguments are hard to explain. When I talk to him, I don't get the feeling I have time or permission to teach him anything."

"Honestly, Long, that's just dumb. You are forgetting a manager has a duty to protect his team. And you know who will suffer the consequences? The team, the product, the customers, and the company, in that order."

"Well, such is the world, Pascal."

Pascal Devoto still searched for words, then suddenly stormed out of the room. The entire office heard three loud door impacts. In the corridor he rushed past a Microsoft banner. It said:

Faster. Smarter. Limitless. Let the AI build your future.

An alliance with Microsoft was announced two weeks later. Stock went up 3%.

On the use of harmful tools

Nando Florestan — Sat, 26 Apr 2025 12:00:00 GMT

…So you are to manage some software creation. Then you must understand you cannot simply employ the same techniques used to manage other domains. Software creation is strange – many counterintuitive truths about it. You will fail unless you learn about these weird realities.

This series contains these posts:

Summary

Big Tech is incentivized to oversell AI’s capabilities. They're marketing it as "productivity" while gutting skilled labor and consolidating power. It's a profit-maximizing maneuver masquerading as innovation.

AI-generated code is not magic. It's pattern-matching, not reasoning. It lacks context-awareness, long-term responsibility, and often produces brittle or misleading output.

Today, Big Tech companies are peddling AI tools before these are ready for prime time. For now, AIs are hallucination machines that cannot be trusted with making decisions without supervision, yet this is exactly how we are already using them.

Big Tech makes insanely exaggerated claims, such as a 3x productivity gain just by using an AI tool. Seduced by these, managers are accepting losses in all the aspects involved in maintaining a codebase, and then hyping their own fictitious feats with AI.

But real software development is a craft. It requires learning, culture, understanding, reasoning, practice, intuition, refactoring, communication... Some of these the AI can do badly; some it cannot do at all. Not yet.

Businesses try real hard not to see that software development is an art. If they see it, they pretend they forget it. However, art has its own requirements, and one forgets these at one's own peril.

Inserting AI as the code writer yields no real increase in productivity – and worse, it requires fundamental changes in the software development process. I will show that some of these changes are, in fact, impossible for humans, though not all humans can see it.

The industry is buying the hype way too early. Developers, managers, even companies are swallowing the narrative before the technology has earned it.

So my thesis is:

Pushing programmers and writers to use smart tools such as AI is harmful and infringes Agile principles.

Though it might seem to be what everyone is doing, it's the opposite of what you should be doing.

After I wrote this post, I found:

an independent evaluation with very similar findings
a Simon Sinek interview in which he says today we are obsessed with output and losing track of humanity in AI adoption.

A word about intelligence

What is intelligence?

Intelligence is establishing true relationships between things previously considered separate and unrelated. Intelligent people show you how things relate between themselves. A void gets replaced by a model.

Contemporary normoses are always due to a lack of respect for the necessary relationships between systems. An obvious example is the lack of relationships between the economy and the environment, even though doing what the environment "demands" of us would be beneficial to all people and all generations.

Why am I talking about intelligence? Well, for the following argument, I need an intelligent reader – one that doesn't have difficulty evaluating new or infrequently made relationships.

I also need a patient reader. I know this post is too long. But fuck you, reader. Read it in 2 sittings or something. To establish relationships between things I need the space.

The argument

If you don't let your students use AI, why do you let your workers use AI?

In education, AI usage is avoided for 2 simmetrical reasons:

Middle school and high school students must not use AI because they must learn to write by practicing writing.
College-level students must not use AI because the output is not college-level.

The same reasons apply to your employees:

Junior devs are still learning to write software, so they must practice the damn craft of writing damn software – not have someone else do it for them.
Senior devs write software much better than the AI, so there isn't much gain for them.
- But also, writing software is a craft, exactly like writing prose is a craft. A craft must be exercised, or you lose it. So a senior dev must continue to write software – or her knowledge, skill and stamina will atrophy.

Now in more detail

The plagiarism problem always existed, it is not new. And there was never a different solution. Plagiarism is not tolerated, ever.

You know a student must learn to write her own dissertation, because that is an essential life skill. You forbid AI for the student – when writing her English assignment – so they will actually practice the skill. If that is the case – why are you doing the exact opposite when it comes to people who work for you?

Every professional writer in the world tells us writing is a muscle that must be exercised everyday. They force themselves to practice their craft every morning and they know they get worse when they don't.

If a high school student must practice her writing, why do you think your worker doesn't need to do the same?

Am I talking about writers or coders? Yes.

This applies to the writing of prose and computer programs, both. There is no difference. A programmer also knows they are worse after a vacation. It takes a few days of work to get back to speed.

Agile is about developing the people more than the process. Improving the process is worthy; but we understand developing the workers has even more value.

Agile recognized that building a great team is the single most important thing the business needs to do. Notice I didn't say hiring a great team, I said building it.

If you are not making an effort to provide the necessary environment and motivate the team to improve, then your organization is not truly Agile.

Therefore, using certain tools by default is against Agile, inasmuch as these tools hurt team building.

Now I will give examples and establish further relations with other matters.

Example 1

To hire a writer, I want to measure her grammar skills. So I ask her to correct the grammar in some text I've written. But she uses AI to do the correction. Now I cannot evaluate her knowledge, it is mixed with the AI's knowledge. Here the AI's knowledge is noise, because it is essentially free for me – I don't need to hire the writer to get AI-level results.

You certainly see the only way to evaluate the writer is to forbid usage of AI.

But then, after she is hired, why would I push her to use AI, if that means exercising her muscles less, and therefore getting worse? Do I want my worker to atrophy???

The HR department, as a system, typically complains that the job market lacks qualified workers and develops means to find and hire them. But after the expert is finally hired, her manager now expects her to be reviewing AI slop, instead of using her expert skills to write?

Can't anyone see this will result in her losing her expertise over 2 years? Or is she now supposed to study and practice her craft in her copious free time?

The artisan exists before the artist. Without an artisan you don't get an artist. You can't have a craftsman that doesn't practice her craft.

The HR department cannot find qualified workers, but hired workers must become progressively less qualified. Wonderful.

How can companies act in such a schizophrenic way? Because businesses lack intelligence, which is the ability to establish relationships between systems that appear to be separate.

Planning the obsolescence of writing itself

But even worse, businesses have been firing writers, since they figure writing is now a job for an AI. Can they really not see the ways in which AI slop lacks creativity and personality? Can they not feel the sterile sameness in everything the AI writes?

But it's even worse: Nadella is peddling a product that liberates illiterate executives from the task of reading. The AI does all the reading for him, and "summarizes". This person believes in building a world in which I carefully write an email and he doesn't even read it!

What a dystopic world, in which human communication will be mediated not just by distance and screens, but also by a summarizing idiot who misunderstands every other sentence!

Nadella might discover he is a replicant himself...

And you thought I was extreme when I wrote "fuck you, reader", didn't you? Well, what about Nadella's "fuck all writers"?

"Never read anything if you value your time!" – That's his advice, and if you follow it, you are one fucked up reader!

If we remember that, in the Gold Rush, the ones who got really rich were those selling tools, Nadella is doing right by his company. But he is also doing wrong by humanity. That's the threat of a new normose, which as we saw before, is lack of intelligence.

This is not prejudice

I have no prejudice or hate against the tools themselves. For instance, look at a sane example:

Even after the computer finally beat man at chess, man continued to play chess. Man did not stop memorizing hundreds of openings, did not stop practicing the endgame, and did not stop playing chess, since it is a wonderful sport for the mind.

The computer changed the game forever, yes. Man now tries to learn from the computer, too. But giving up the skill and letting the computer have the chess game for itself, that's what we are incapable of doing. In fact, chess is now more popular than ever.

It's not about winning, anyway. It's about the Olympic spirit.

Get better than you are now – for you are a man.

AI currently sucks hard at creative endeavors. It is okay at reformulating existing language, improving the vocabulary used, and maintaining coherence (as long is it understands the content). But it's awful at creating literature, stories, jokes, poetry, music, art etc. But suppose AI does become good – would man give up the arts?

Of course not. Not in a million years.

Be a man. Get awesome.

Example 2 (mild)

Woody Zuill tells a story. A couple programmers on the team were delivering code in which the architecture left something to be desired. Instead of having the code corrected, he tolerated it while giving the team ample time and incentive to study these matters. In just a couple of weeks, the devs had acquired the skills and were themselves correcting those mistakes. No feelings were hurt, the team was enthusiastic (due to learning), and Man did what (s)he is supposed to do: learn and improve.

Zuill temporarily sacrificed product quality in order to develop a happier and more capable team. That was the wise choice. Is this what most IT companies are currently doing???

Or are they saying you shall be happy vibe-coding? Are you going to be happier in your relationship to a human team, or by becoming a cyborg?

Example 3 (the kicker)

I will leave you with this example by Dave Farley, which I invite you to watch in his own words. But I will paraphrase his tale here if you prefer to read:

Dave gets hired a second time by the same company to rescue a problematic software project. Dave realizes a certain dev doesn't know how to code – the guy even avoids for loops in Java because he doesn't know how for loops work. The dev is an impostor. Dave tells the company, this guy shouldn't be working here, he is not good enough. The company answers, what do you mean, his code review skills are legendary in the company. In the end, it is discovered that the guy simply used an IBM tool for code reviews, and understood none of it.

Now imagine how much financial loss that employee was responsible for:

His own salary for years.
The damage he caused to the codebase every day, putting the project at risk.
The rates of the experts eventually hired to rescue the project.
The administrative decision making, required to hire the experts.
The license paid to IBM for a tool that is actually harmful to the team.

(The last bullet is mine, not Dave's.)

Exercise for the reader

Obviously, constantly using AI can be even more harmful than the code review tool; but I want you to think about something else:

From the story above, what can you conclude about the practice of code reviews? If a complete amateur can hold a job by using a tool to do code reviews, doesn't that say something about code review as a practice?

Why don't you think about it first? Next I'll tell you what I think.

The hysteria about AI

The most current and modern tremendous mistake being committed in the IT industry is, of course, the premature acceptance of code written by AI, disregarding every aspect of it just because it gets done fast.

The AI companies affirm the AI is equivalent to a junior developer; the managers have no experience of the actual work of producing software, so they believe that hype and stop hiring juniors.

Then juniors do not, over time, learn and become seniors and soon the industry will be devoid of qualified workers.

AI cannot yet replace humans because its experience of the world is too limited.

It cannot be aware of the whole project in one prompt/interaction.
It cannot compile the code it writes.
It cannot execute the automated tests.
It cannot ask for clarifications.
It cannot ask for the opinions of team members.
It has no concept of the history of the project.
...

So it's easy to see that comparing a simple tool to a human is nonsensical. Saying an AI is equivalent to a junior dev is to see the junior dev only within the task of writing some code, as if that could be done without all these other tasks.

The truth is, code written by AI is:

as mediocre as the code it was trained on,
full of hallucinations,
not yet compiled, not yet tested, not discussed, not aligned with overarching goals of the project,

...and by the time the developer takes care of everything that is missing, which is boring work, any productivity gains have been inverted.

Further, it has recently been discovered that using AI for coding has become insecure, due to a new kind of attack called slopsquatting.

Nevertheless, in this video, Theo realizes that code written by Artificial Intelligence is a reality in companies and that we need to adapt our workflow. Then he makes the most obvious mistake: He thinks we need to improve our ability to review code.

I like Theo's videos because his takes are always mistaken and short-sighted. For instance, his irrational hatred of Flutter, which is a lovely piece of technology. When I agree with Theo on something, I know I need to think more!

Code review is a scam

Another effect of AI is that a programmer is no longer a programmer. She is just a code reviewer now. The AI codes, the dev reviews.

As a developer, I am now supposed to be slowly reviewing code quickly written by a moron (the AI) –, which is a job I hate.

I became a developer because I love programming. They are taking away the creative activity I love – writing good code, using skills acquired over decades – and telling me to do something boring instead: fix bad code, all the time.

Further, there is no way to teach a person to be a code reviewer. That's impossible. You can only learn to program, and then, after you program well, you can review code, badly.

One learns to program by programming, not by reviewing code. The practice of programming is indispensable. One cannot truly understand, for instance, object-oriented programming simply by reading a book. The practice of it is what finally teaches you.

The same applies to libraries, not just programming languages. You start a code review and you see the AI wrote this:

import caprese

You have never seen this caprese library before. (Assume the library is legitimate; I am not talking about the security problem mentioned above.) What do you do now? You know the AI hallucinates. Do you blindly trust its usage of the library? Or do you start reading the documentation of the library?

Remember, management told you to work faster by using AI. How much time should you now spend validating the AI's hallucinations about this caprese library?

Are you so inexperienced in codebase maintenance that you allow any unknown library to enter your dependencies – much less a library suggested without any consideration of the rest of your codebase?

Beyond security problems, have you never had a library become unmaintained and start generating thousands of warnings after you upgrade the version of your programming language?

You are an expert; how on Earth did the powers that be conclude you would work faster by reviewing the thoughts of an idiot? Do they not know that software development is an immensely complex craft? Is it not insulting to you that they see you as a monkey typing words on a keyboard?

And how are you going to learn to properly use the library if you are not even programming anymore??? You think reading documentation makes up for it??? Have you never heard of Constructivism?

The philosopher Ludwig Wittgenstein affirmed that man can only truly understand that which he creates.

The idea that human programmers could ever become just code reviewers is the single most absurd thing I have ever heard in this industry.

But it's even worse than that. Code review itself is a mistaken practice.

I realize that reviewing code is impossible. This is because writing code is a creative activity that begins with the programmer concentrating on all the information necessary to write the code, including how the thing works right now and how the thing should work tomorrow.

Whereas reviewing code doesn't start from the same point. It starts with the subject reading new code, at which point several assumptions happen.

The user story, the objectives, the necessary information that drove the writing. Do you think the code reviewer can be as aware of these things as the code writer was?

And there was a process. Maybe the code was written, then rewritten. But the reviewer is absolutely unaware of the evolution of ideas in the mind of the writer.

In practice, the code reviewer's preoccupations are different from the code writer's, and that creates problems.

As a simple matter of human perception, conscience after creation is much deeper than conscience after revision.

In a code review one probably should question everything, but that is impossible to do. In reality, only a handful of things can be questioned in a code review – and then we are tired.

This is why, in years and years of experience, code reviews have never been able to catch enough bugs. It is absolutely necessary to test all the written code. And before testing, you need to understand the impact of the change so you know which screens and which use cases need to be tested. And if you don't test, there will certainly be problems despite the greatest possible skill in reviewing the code.

…just like UML was a scam

There are similar mistakes that have been made in the history of programming – for example, a focus on UML. For a long time, there was a class of programmers who did not use a code editor, they used Word or software to make diagrams. They were what we called office programmers. Gradually, the focus on diagrams was abandoned, because a programmer, in order to think correctly, needs to be in front of her editor, not in front of tools that only express abstractions and do not compile.

They say "paper accepts anything". That's the problem with diagrams. Also the problem with code reviews.

A code review does not occur in a text editor, it occurs in a code commenting interface. Just as UML could be divorced from reality, a code reviewer also has trouble seeing reality for what it is, and may make suggestions that either aren't practical or do not aim at the objective of the current user story, because a reviewer is not so conscious of either, compared to a creator.

The alternative to code reviews

(Pair programming is the right answer.)

At the moment of a code review, I don't anymore do a code review. I become co-creator instead of reviewer. I do code changes, and then I ask the original developer to look at my changes. This is the only way to ensure the code review doesn't descend into nonsense.

I open my editor and I rename the variables that are poorly named. I add the else clause that is missing after the if clause. With each improvement I make to the code, it becomes possible for me to see other problems.

If I didn't solve the issues I already saw, I wouldn't be able to see further. I don't know why this is so, but this is how my conscience behaves. I have to open the tomb first, then I can see the spider webs. I have to clear the webs, then I can see the dust. I have to clear the dust, then I can see the hieroglyphs.

A man walks into a doctor’s office, frantic. "Doctor, you’ve got to help me! I think I’m going blind – I can’t see a thing out of my left eye!"

The doctor looks at him carefully and says, "Well, that’s serious. But I also notice your right leg is missing – what happened?"

The man waves it off, "Forget the leg! That’s old news!"

This is why code reviews fail: people are unable to agree on what to focus on. Cognitive overload and tunnel vision are common realities.

When I review code and ask for certain changes, the programmer often misses my point and creates a third strange version. Showing a better result (and letting them compare) is more effective than meta-talking about an idea that for the present is only in my head.

So code review is not possible as code review, it is only possible as code maintenance done in an editor.

Pair programming, or mob programming, is the right idea. Code reviews are too late, too tiresome, too costly and too ineffective.

AI does not edit

But it's even worse than that.

AI is a machine that creates legacy code. The challenge with legacy code is understanding its intention, which has been lost because the people are no longer there. If only the original developer were around, you could ask her what led to certain decisions. The reasons for the code to be this way.

But in this case, the intention – if it ever existed – is impossible to determine, because the AI does not have a personality; it has different beliefs, priorities and knowledge each time you run a prompt through it. The output can be markedly different even if the prompt is always the same.

AI is unable to edit code – it can only rewrite code. This leads to a huge patch each time. Instead of a laser focus on the detail that needs changing, you get a completely new program! How on Earth can you manage that?

This is such a messy way to work and understand code that any productivity gains – which are all lies, by the way – would be reversed by the time the bugs hit production.

The mess created by using AI – a mess that affects the diffs in the git repository, the ability to reason about the code, the expertise of the worker herself, and the fun of working, is so grave that no ability to type code faster can compensate.

Managers never explain the reason

I believe most of what I am saying is obvious to any developer, but humans are terrified of going against the mob. In this case, AI hype and greedy managers have already created a mob.

Let us read an example told in a YouTube comment on 2025-05-28. This person is a video editor in a large company:

(...) Everytime I or anyone makes suggestions on shooting photos or video with real environments we’re asked to “think how we can incorporate Ai into it” or even just skipping hiring models and actors to use Ai instead.

Where I work, the executives, directors and managers don’t want to listen to creative professionals or employees with the skill set. Speaking up just puts a target on your back. During my end of year review, the only thing they told me to work on was to “embrace Ai more”. The CEO even had to write a company wide email about how “our industry is moving towards Ai and we need to follow”. Funnily enough, had he just made Ai write that email, it wouldn’t have sounded so cold and depressing.

But notice how managers are always prescriptive, they never explain anything. The pressure of using AI now... is postulated, not proven. There is never any justification given for the new directive, much less one that would survive some scrutiny.

The real message is, AI is faster and cheaper, therefore it shall be used, even at the expense of everything else:

The sanity of the team
The jobs of the team
The sanity of the process
The knowledge, expertise, and wisdom acquired over decades
The quality of the product
Customer satisfaction
Everyone's humanity

...and the only thing that remains possible is for managers to pat themselves in the back, self-congratulating for gains that are, in fact, false. Such managers should embrace AI by stepping down. Even an AI would do a better job.

However, in the end, the proof shall be in the pudding. Companies that "embrace AI" in a stupid way will certainly suffer.

Conclusion

A programmer must program as a writer must write as a pianist must play. Smart tools can hinder the exercise and development of one's craft.

AI spoils man's memory, thought and self-improvement. It can type lines faster, but in a manner that is not manageable, and people are going to suffer and die for this reason.

Companies must realize the importance of motivating people to develop their craft and become their best selves. Companies that push a tool that will hinder the development of the team certainly are not Agile.

Architecture before coding was divorced from reality. Estimates in software were divorced from reality. Waterfall was divorced from reality. The solution to these three was never to learn to do them better; we tried that and it failed. The solution was to stop doing them.

Code review is like that, it is the great mistake of this generation. We will spend 25 years trying to review code, striving to do it better. Finally we will realize what Wittgenstein and Constructivism already knew: Building it yourself is an essential step to understanding it. Humans cannot review code well, they can only write and maintain code well.

You can do pair programming with a human, but not with an AI. If you can only review the AI's code, then that's not a realistic option, since code reviews are insufficient.

AI cannot yet replace humans because its experience of the world is too limited. But by abusing our interim hyped AI, we are having it replace quality, accountability, and the soul of engineering.

Ultimately, we are talking about Robert C. Martin's maxim: "The only way to go fast is to go well". The problem is not new. Software developers, as professionals, have the duty to say "no" to every ignorant management measure that hurts development while trying to make it faster. It is a disgrace that so many professionals swallow it.

No estimates!

Nando Florestan — Fri, 25 Apr 2025 12:00:00 GMT

This series contains these posts:

Estimation is impossible

From other fields came the notion that deadlines can be set. But one of the most striking bizarre facts about software creation is this:

It is impossible to anticipate when the thing will be done with any reasonable amount of certainty.

This was gradually discovered during the history of software development. It is impossible to estimate development effort, because in programming, difficulty is accidental, it is not predictable. One does not know what the trouble is going to be.

If you cook pierogi once, you have some idea of how long it will take you next time. But new software is like writing a new book or researching new tech. Treating it like pierogi is so wrong, it is offensive. Only in very few cases is software so repetitive, and in those cases, it is not very valuable. Valuable software does something new enough that you can't estimate it.

In such cases, I don't know how long it's going to take, because I haven't written it yet.

History

Since the 70s, devs marveled at how much their estimates were off. So they concluded: "we should improve our estimation skills. Learn to estimate better through deeper thinking". Research on this was done in the 80s, and they came up with better techniques. Then they saw the results were equally off. It wasn't until the turn of the century that a few enlightened minds decided estimation was a waste of time. The result of the estimation was garbage, so they wouldn't do it anymore. They wouldn't lie to management.

This idea only began to spread about 10 years ago. That's the #NoEstimates movement.

Rubbish

The last time I estimated a story with Raphael, we spent 3 hours and came to the same conclusion, so we felt good about it, although we were extremely tired. But then a better alternative came up and plans changed, so the 6 man-hours were thrown away. The estimate would need to be redone, and in all that time, nothing useful was being done for the user/client.

The 6 man-hours were pure waste: doing the estimation hurt the speed of the team. The estimation was probably incorrect even if we felt good about it, and even if it weren't so, it had no value once we had a better idea and changed our plans. If you want your team to be fast in delivering working software, requiring estimates is a great way to ensure they will be slow.

So, you see, in software, estimation doesn't work, its output is garbage and management decisions, business decisions, must not be based on such poor quality information.

Developers always knew estimates are rubbish, but managers always insisted they need it. Managers won, but nothing could be done about the fact that, in software, estimates are garbage.

Software creation is an interaction

When we estimate, we sort of write the software in our heads. We start scribbling that, to finish this feature, we need to write these new database tables, this database migration, these business rules, these API methods, use this or that library, add this and that to the GUI etc.

But that's not how it actually works. When we sit down to do the actual work, we are faced with the entire iceberg, not just the tip we could see.

Initial estimates often assume a "greenfield" scenario, but in reality, we must integrate with legacy parts of the system, poorly documented code, or unexpected architectural bottlenecks.

We make bets. After some software is written, we start to realize whether our bets were off. Only through building can we understand the true problem and discover better solutions. We are now interacting with all sorts of unanticipated forces:

Requirements were vague, evolving, or misunderstood.
Real needs become clearer only as the product takes shape.
Underdeveloped designs.
Edge cases, usability concerns, or integration issues emerge.
Unforeseen technical debt.
Models may be different than how we remembered them.
Libraries are at least partially unknown.
The compiler.
Versions.
Discovery of steps we didn't anticipate we'd have to do.
A developer doesn't just develop. She gets sick, she must go into meetings, she needs to pause to fix a bug, she needs to do some planning, she needs to answer e-mails and someone else's questions, she needs to research something before the next sprint... None of this gets factored into an estimate.

In short, writing actual software is a struggle against realities that were completely unknown at the time of estimation.

Implementation is discovery, not execution. This is why Agile emphasizes iterative progress, continuous feedback, and adapting to change.

Managers do not understand the word "estimate"

When you use estimates, you set yourself up for this eternally repeating conversation:

"The feature is not ready??? You said it would only take a week."

"That's not what I said. I gave you an ESTIMATE."

"That's bullshit!!!"

"You got that right!!!"

"How can I meet my goals like this???"

"What do I know about YOUR job??? My plate is already full of this letter soup!"

What to do

Developers give estimates just so managers will stop pestering them and go away. That is an irresponsible thing to do. The only responsible thing is to deny estimation.

However, businessmen still need information to be able to make business decisions. There's an event later this year, that is an important business opportunity, and we need to be able to predict what can be ready by then.

That is why people have been studying how to make management decisions in the absence of estimates. Based on other criteria.

Not convinced?

I do not expect you are convinced. I was only convinced after weeks of consideration. But this 37-minute presentation by Allen Holub is what finally convinced me.

After 15 minutes, he starts to show how to manage a software project in the absence of estimates, including how to count stories to make graphs and calculate timetables. After 31 minutes he recommends Story Mapping to organize the backlog and prioritize features for the next release.

Other notable authors about NoEstimates are Woody Zuill and Vasco Duarte.

Counterintuitive facts of software development

Nando Florestan — Thu, 24 Apr 2025 12:00:00 GMT

This series contains these posts:

The book

One of the most interesting and lasting books about software development was written in 1975. That's "The Mythical Man-Month" by Fred Brooks.

On Waterfall

I will base this post on famous quotes by him, mainly from that book. Always in italics:

"The Waterfall Model is wrong and harmful; we must outgrow it."

Yep, that's what you learned in the first post in this series. Brooks already knew it.

Brooks' Law

"Adding manpower to a late software project makes it later."

The above sentence is known as Brooks' Law. It's probably the most famous quote from his book. It sums up one of the most interesting and counterintuitive things about software.

Suppose you are managing a team and the project is late. To fix the situation, you hire one or two more people. You do this because more people will certainly get more work done.

One month later, maybe two months later even, not only the situation hasn't improved, it's gotten even worse. You wonder why.

First reason for Brooks' Law

The most important reason is that communication overhead increases when someone enters the team. All sorts of information must be asked by the newcomers and answered by old team members:

about the domain (e.g. accounting in an accounting system)
about how things work in the system
about why things have to be this way
about why the team works a certain way
about difficulties using the tools
about the correctness of one's own work
etc.

The communication need is so intense that weeks can pass before a new team member becomes properly productive, and while providing explanations, the experienced team members also have their productivity impacted.

You want to know how to make this even worse? Try to preserve the experienced team members from communication up to a degree, or even entirely. Now the newcomers have no clue what they are doing and have no way to learn valuable things that were already in the culture of the company. This is because a great amount of knowledge in the team is tacit, not explicit. Only communication makes it explicit.

And that is no way to treat a new team member, of course. It conveys that experienced team members are too busy or too valuable to teach anything to the noobs. This leads to conflicts and hurt feelings and hurts team formation.

There is no way to avoid the need for communication, because, in a way, software development is knowledge production. Every new person increases the communication overhead dramatically, leading to miscommunication, coordination delays, and diminishing returns.

As a rule of thumb, the larger the development team, the more time needs to be spent in communication, even after everyone is onboard and productive. As Brooks says:

"The number of communication paths increases with the square of the number of people involved."

This is a good argument to keep software teams small. And this is why in Agile no team is larger than 12.

Second reason for Brooks' Law

"Nine pregnant women cannot produce a baby in one month."

This is one of the funniest. Brooks explains:

"When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned."

This is about activities and decisions that depend on the completion of others. A manager needs to understand how such dependencies happen in software development.

"Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them."

This means, only when bits of work do not depend on each other, can they be done at the same time.

On business analysis

"The hardest single part of building a software system is deciding precisely what to build. The most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they have almost never thought of the problem in the detail that must be specified."

The entire development team does business analysis: they try to understand the steps through which work needs to be done. That quote is amazing near the end. It is often said that clients only know what they want after they see what they don't want. Meaning the team presents a design first, and then the client can see flaws in the design and correct it. But the client is unable to describe what is desired before they see the design.

The last sentence... "in the detail that must be specified"... is explained in another terrific quote:

"Design work doesn't just satisfy requirements, it elicits them."

Meaning, the requirements exist, but are not known by anyone, until a design suddenly makes them obvious.

Also, the design must go through iterations. Each iteration allows the team and the client to discover new weaknesses and needs:

"Even the best planning is not so omniscient as to get it right the first time."

Every now and then, no argument will convince an egoic client with enough bad taste:

"Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer."

Software designers are strong in a certain kind of abstract thought, which allows them to see shapes of solutions that apply to many different problems.

"I am more convinced than ever. Conceptual integrity is central to product quality."

I found the same thought expressed in another quote:

"Conceptual integrity is the most important consideration in system design."

Software follows and materializes rules. You cannot establish rules unless you are thinking very clearly. In software as in law, good rules are based on sane concepts; bad rules use bad criteria. Confused concepts will always hurt decisions made by or with the software.

It's not requirements

The word "requirements" is still used, but now it's wrong. None of those are required. They are just ideas, and their priority is always shifting as the business learns about the market, about itself, about current needs etc. Many of those ideas necessarily will be discarded, which wouldn't happen if they were requirements.

An Agile team treats potential features as ideas, not requirements. This clarification is repeatedly made by Jeff Patton, inventor of the Agile technique of Story Mapping.

Bugs are priority zero

Some people have a notion that they are going to manage bugs. They think they can list the known bugs and decide which ones to fix. They want to save developer time spent on bugs!!! That's outlandish.

A bug usually is bad behavior whose origin is unknown. If you are seeing 2 buggy behaviors, they might have the same origin in the code (in other words, they might be the same bug).

If you let bugs live, they can get compounded. A bug interacts with another bug, creating a third bug. At this point, no sane person can understand what is going on with the system.

If you try to manage bugs, basically you don't understand what the hell is going on anymore. It is hard enough to reason about working software; who can reason about bugs?

The notion of managing bugs is as absurd as the idea of managing mysteries.

The only sane thing to do about bugs is to squash them as soon as they are seen. Now maybe you can reason about your system.

If I wished to reason about insanity, I would have studied Psychology, not Computer Science.

More than 40 hours a week hurts the project

Programming is an activity that requires a very high level of concentration. The brain works very hard and gets tired.

When a programmer is overworked, his productivity goes down, he feels tired, his concentration is feeble and his decisions are worse. The quality of the software goes down and sometimes the programmer can produce more bugs than features, effectively hurting the project.

A developer must work 40 hours per week, tops. No more.

Do not pressure developers to work faster

The business wants software produced as fast as possible, so it puts pressure on developers.

Developers have only one way to deliver faster: drop the quality of the writing.

So the software is now more buggy and less maintainable.

Now the business pays the price of the bugs, which is enormous (annoyed customers, no satisfaction, no word of mouth etc.). Fixing bugs also gets exponentially costlier as time passes:

Fixing a bug in the developer's machine costs ~2 minutes.
Fixing a bug in the staging environment costs around an hour. One has to fix the bug, then deploy the fix, then let the customer know it got fixed.
Fixing a bug in production takes a day in some cases, because data is already wrong for the users. If it's not a web app you also have to push a new version out and its adoption will vary according to the effectiveness of the software update system.

You can sort of understand this if you think of an author writing a novel. You as an editor tell the author to hurry up. So the author forgets to do certain edits. Now the character that got killed in chapter 6 suddenly reappers in chapter 18 without any explanation.

In software this is much worse than in a novel. To compare, you'd have to turn the novel into a virtual reality. Now you have a Shrödinger's cat who is alive and dead at the same time. What could be worse than that in software?

But that is not the only bad consequence. Badly written software is harder to change. This means future tasks take much longer to accomplish. So you thought you were saving some time, and maybe you did if lucky, but you've hurt the entire future of the project.

Robert C. Martin expresses this concept best:

"The only way to go fast is to go well."

Pressure your developers and suffer the consequences.

In Agile, the quality of the code is not negotiable. It takes as long as it takes. Bad managers need to get a clue.

Technical debt

No novel is written right the first time. Every romance needs a few rewrites to become really good. Software is similar. Some parts of the software need to be reformulated, because it is impossible to get it right the first time.

Even if you don't have bugs, you have badly written parts. You are paying for these parts each time a developer needs to read them or change them. So they are worth fixing even if the fix does not change the external behavior of the code.

In a novel this would be the same as telling the same sequence of events, but telling it in a better way. Maybe the order of the chapters change. Maybe it's the vocabulary and the wording. The story itself doesn't change, but the novel becomes much better. Prevent the author from doing his rewrite, and you are hurting sales. Also worth remembering: sales aren't the only thing that matters.

Ward Cunningham is an Agile developer who is one of the creators of XP (Extreme Programming). He also invented the wiki – the notion of a collectively edited website in which creating and linking pages is very easy to do.

In this video, Cunningham talks about how he coined the famous metaphor of "technical debt" to explain to non-technical people the necessity of refactoring code.

Basically, rushing the software out the door (badly written, hard to understand, hard to change) is initially good for business, but it is like taking a loan. The debt must be repaid in the future, by spending time to refactor the software, so it becomes again easy to change.

Woody Zuill expresses the same thing in more broader terms. He says "teams and managers should spend the time to make the work easy to do".

Refactoring, and fixing technical debt, is about making future work easy to do.

Truck number

Some teams have programmers "own" parts of the codebase. Joe is the one who understands this area. Sue is the one who can fix problems in this other area. The devs are experts in parts of the code.

That's the worst way to distribute expertise. It results in low Truck Numbers.

What is the smallest number of people in your project that, if hit by a truck, would put the project in trouble? That's your Truck Number.

If only Derek can manage the positronic code, then your Truck Number is one, and that is too low.

The solution is obvious. Nobody can "own" a part of the code. The entire codebase is collective. Everyone works on everything.

This forces the team to share knowledge, resulting in a better team.

Pair programming

We have just seen how important it is for the development team to be constantly sharing knowledge.

That is one reason to program in pairs.

If an experienced dev works for a few hours with a novice, teaching is automatically taking place.

There are more reasons, too.

The one on the keyboard (called driver) is helped by the other one, who does research as needed and removes other blocks.
Better automated tests are written, since one remembers what the other one may forget.
The code is examined by two people as it is being written. One sees the bugs of the other. The quality of the result is much higher, with much fewer bugs. No code review step is necessary.
The alienation and isolation typical of a software development job are eliminated. People are interacting again. Having fun at work.

This is just one more strange thing for managers to realize. Managers who don't know about pair programming think it's waste. Two people doing the job of one. Nothing further from the truth.

Pair programming is one of the prescriptions of Extreme Programming, an Agile methodology.

Don't tell me how long it will take

After working with a software development team for a while, a manager begins to feel how easy or difficult tasks are going to be, even if she never does any task herself.

Sooner or later she catches herself saying in a meeting, "I assume that's only going to take five minutes to do". That's natural, but please, blush when you say that.

First of all, nobody knows how long it's going to take. Not even the developer. Because he hasn't done it yet. If it's more than changing static copy on screen, it could vary.

Second, it's arrogant, defying and disrespectful. Writing software is not frying pancakes. More about this in the next post, about NoEstimates.

Conclusion

If you've read this far, congratulations: You have just remembered universal truths about software development that have been known since 1975 at least. But these are frequently forgotten, which is a shame to those involved.

How to hire a development team

Nando Florestan — Wed, 23 Apr 2025 12:00:00 GMT

This series contains these posts:

This is the first of a series of posts for administrators, although programmers should read them, too.

The question

As a business person, you are focused on the big picture, and you need your contracts to be precise to avoid unpleasant surprises. So here is my question to you:

Would you hire a software development company that works via the Waterfall method?

Yes or no? Would you hire them to make software for you?

If you don't know what Waterfall is, you are in the right place.

By the way, the correct answer is no, you mustn't, because Waterfall is a severely obsolete way to develop software, and likely to fail hard. But Waterfall continues to be used today, since it feels comfortable to administrators who do not know certain strange facts about software development.

Waterfall

Waterfall means each development phase is done for the entire scope of the project and its output informs or cascades into the next phase:

Requirement gathering & analysis ↘
   System architecture and design ↘
                    Implementation ↘
                            Testing ↘
               Delivery / deployment ↘
                            Maintenance

The first phase, requirement gathering, results in a text that states the problem we are trying to solve. This text is the basis for work on the second phase, design, which is done by business analysts interviewing workers in your company, and results in a text (and some diagrams) that state what the solution is going to look like.

You pay for these 2 phases and, if you are happy with the proposal, you contract the team to actually develop the software for you. So you start paying for development, but basically you don't talk to the developers anymore, for months or even years, until they finish their job and come back to show you the result.

That output of the 2nd phase is the input for the 3rd phase, implementation, in which programmers make the software. The application is the input for the 4th phase, testing, in which testers find bugs in the software and send those back to the programmers to fix.

Problems

When testers are happy, you go to a meeting and you see what they did. Now you start pulling your hair because:

Due to misunderstandings, what they are delivering is NOT what you asked for, months and months ago.
Even if they had understood you, so many months have passed that what you asked for is no longer what you need. During this time, your business has evolved, your customers have changed, regulations have changed, the market has changed etc.
There are features missing which are evident now, but nobody thought of then.
The project is late and you have already been forced to negotiate the price, paying more for them to finish the job.

Historically, the Waterfall method had these serious problems:

It naively assumed that the system could be planned in its entirety; it did not foresee changes in scope.
Each step took months to do, so projects could take years to complete.
Clients did not participate in the development process, they only saw the finished project at the delivery phase.
For lack of communication, clients felt what was delivered had almost nothing to do with what they had said they wanted.
By the time the project was completed, the plans were obsolete: so much time had passed that the solution was born inadequate. Even if there had been no communication issue.
Each phase was driven by fear of incompleteness. Most importantly, during the initial requirements gathering, clients tried to be as complete as possible in listing features, for fear of leaving out something important while they still could add scope without incurring costs. This resulted in implementation of many features that were never used in practice – an enormous waste of time and money. This problem is called "feature creep".
Due to lack of communication and lack of trust, negotiation was hard. Clients simply wanted as much scope as possible for as little money as possible. It was hard for clients to understand why no software project can be delivered in the estimated time (more about this in another post). If legislation changed during the project execution and the scope had to change, a negotiation had to take place.

Software projects are very different from other projects. Software has weird characteristics that you, as a business person, must know about, if you are to succeed. This is what this small series of blog posts is about.

Fixing waterfall

Around the turn of the century, Waterfall was gradually abandoned, in favor of some Agile methodologies. But here is the problem: Agile is hard to understand.

Let's just try to begin to understand Agile.

The word Agile does not mean faster. Nothing gets done faster. It just means our reaction time is shorter. When the environment demands we move in another direction, we are ready to do so. We are a motorcycle, not a train. A motorcycle is not necessarily faster than a train; it is more agile.

What would you do to fix Waterfall? I have shown you its problems; what do you do?

Here are some obvious things:

The client must participate all the time, not just at the beginning and at the end.
There should be more communication.
Planning should not be done only once at the beginning of the project. It should be done all the time, as reality changes and priorities shift.
Place incentives to get rid of the fear of incompleteness. Tell them to make a small improvement and deliver it as soon as it is palpable to the user.

Therefore, when working with an Agile team:

You are required to enter another kind of contract, with variable scope, as opposed to the fixed scope of the Waterfall method. In other words, the contract does NOT say what the software is going to do. Nobody knows what the software is going to do, exactly. That's going to be discovered during the project. You pay for development time, not for a fixed scope. As an administrator, at first, you preferred a fixed scope, but now you know it would cause the project to fail.
You accept a Minimal Viable Product (MVP), start using it, and work with the team in short iterations, giving them priorities and meeting to see increments in functionality. The most painful aspects of the current software will always be very obvious to you.
You must stay in touch with the development team to fix misunderstandings early and provide an updated north to them. In fact, you are part of the development team.
The team avoids Almighty Thud Methodologies. The Almighty Thud is the noise that the documentation makes when it drops on someone's desk. Documentation is not software, though. It is only valuable in small portions.
Everyone must understand that the scope changing... is the norm, it is the most common thing in the world, it is not to be treated as an exception, but as a rule. ("Embrace change" is the subtitle of Kent Beck's 1999 book on XP.)

Now I want you to look at the phases of a project again, because it is impossible to change these:

Requirement gathering & analysis ↘
   System architecture and design ↘
                    Implementation ↘
                            Testing ↘
               Delivery / deployment ↘
                            Maintenance

Our purpose is to reach Delivery. But we can't deliver something that wasn't Tested. And we cannot test something that was not Implemented. And we shouldn't implement something that wasn't Designed. And we cannot design something if we don't know what the problem is.

Therefore, the steps above are the same in Agile – but they describe only one iteration of many in the project. The iteration lasts only one or two weeks and works only on a small fraction of the system.

In Waterfall, you might choose to hire testers only near the end of the project. In Agile, everyone is working at the same time. The pains of one role can immediately be conveyed to relevant others. The system architect is immediately informed of the weaknesses in her architecture. The business analyst is immediately informed of the weaknesses in her output. The programmer immediately sees what kinds of bugs are being found by the tester. Everyone gets opportunities to improve – immediately, not just at the end.

Instead of the feature creep characteristic of Waterfall, Agile prefers to deliver the smallest thing that has any value to the user as soon as possible. Even if it's just a single feature. The software is continually updated.
We get feedback from the client and especially from users as early as possible and use that feedback in the following iterations. More likely that the right thing will be implemented. Less likely that unnecessary things will be implemented.
Bring the client onto the development team, so there is transparency, they can actually see the hard work being done, they gain trust, and communication switches from negotiation mode to team mode.
Even if communication fails hard at the beginning of the project, chances are it will improve and the right thing will be developed.

When do you stop the project? Well, it seems software needs to be maintained forever, to keep up with the times. But for new features, you know when to stop. Every two weeks you are focusing on adding the most important or most urgent feature(s). So you stop adding features when the cost of development finally becomes higher than the benefit of the remaining features listed in the product backlog.

Conclusion

Maybe Waterfall can succeed for projects that are small enough or very easy to understand and describe. For instance, a device driver for a mouse. But most software projects aren't like that, and then you need something that deals with the actual challenges, and that's Agile.

Since 2001 more or less, the software world started employing Agile methodologies. However, because of the exponential expansion of software, many do it without fully understanding it. Even today, many have heard the rooster announce dawn, but don't know where it is. They are just waking up to the new day.

There is nothing on the horizon that can replace true Agile, there is no newer idea worth our time. Our current problem is that our Agile must be true, that's it.

The next post will talk about other strange things typical of software development.

Dart versus TypeScript

Nando Florestan — Tue, 06 Aug 2024 12:00:00 GMT

In recent posts I have shown that the web only has crummy technologies, but at the same time, Flutter deployed on the web is not yet free of its own crumminess, since it runs slower than in any other platform.

In this post I shall convince you, beyond any doubt, that to develop frontends, you should use the Dart language rather than TypeScript. We'll examine:

Problems with JavaScript
Ignoring those problems like ostriches
Problems with TypeScript
Problems with functional languages
Dart as a solution
Problems with Dart
Conclusion
Futurology

1. Problems with JavaScript

JavaScript was created in 10 days and now we have to tolerate it forever!? WAT. It is the only language I know with so many evil parts, other than INTERCAL.

The best book about it is called "JavaScript – the good parts". Everyone has read that book. However, its author now says it's time to stop using the language.

The design problems in the JavaScript language are too numerous to list here, but here are some of the most egregious:

this keyword
- Context sensitivity: The value of this can change depending on the context in which a function is called, leading to unexpected behavior and countless debugging sessions for thousands of developers.
- Binding issues: Developers often need to use .bind(), call(), or apply() to explicitly set this, which is cumbersome and unheard of in any other major programming language.
- Arrow functions: Arrow functions do not have their own this context, which can be both a benefit and a source of confusion when switching between arrow functions and regular functions.
Arrow functions
- Implicit return: The concise syntax can be misleading, especially with object literals, where {} is interpreted as a block rather than an object.
- Arrow functions do not have their own arguments object, which can be limiting in certain scenarios.
- No own this: While it solves some problems, it can also be confusing when developers expect a traditional function's this behavior.
Type coercion
- Implicit coercion: JavaScript's automatic type conversion is a severe misfeature that leads to unexpected results, such as '' + 1 resulting in '1' or true + false resulting in 1.
- == vs. ===: The loose equality operator == performs type coercion, which can lead to unexpected results, whereas === does not, leading to a general preference for the strict equality operator but also to confusion among new developers.
Classes and super()
- Syntactic sugar: JavaScript classes are often criticized for being syntactic sugar over the prototype-based inheritance, which can lead to misconceptions about how inheritance works in JavaScript. In reality this is not a problem in itself, except for all the terrible implementation details in classes, this and super, which become a list of gotchas for developers to memorize.
- Mandatory call: In a derived class, if you define a constructor, you must call super() before you can use this. Forgetting to do so results in a reference error. But worse, this means it is impossible to completely override a constructor in Javascript.
- Order of initialization: The call to super() must happen before accessing this, which can complicate constructor logic and initialization sequences, or even make one's idea impossible without a redesign.
- Classes in JS are so bad that most JS developers prefer to ignore them entirely. Instead, they achieve encapsulation by abusing closures, which is in itself another terrible way to write software.
Module systems
- Due to historic reasons, JavaScript has multiple module systems (CommonJS, AMD, ES6 modules), which can be confusing and lead to compatibility issues.
- The final system (ES6 modules) has a export default feature which I don't see in any other language, does not add value per se, and probably only exists to emulate the previous 2 module systems.

JavaScript is a language notorious for its inconsistencies and flaws. Despite possessing modern features, it suffers from fundamental issues that remain unresolved. this, function, arrow functions, super, and the, so to speak, excessively dynamic type system... the behavior of these things is riddled with exceptions and unexpected outcomes. Learning JavaScript often feels like memorizing a long list of workarounds.

As a result, JavaScript is a language that makes kittens cry every day. It is legitimately a language to be hated, if we are being reasonable.

JavaScript is a hypocrite, like a person who pays for expensive, albino-white facades on their front teeth, but leave their back teeth to rot full of caries. JavaScript is the guy with a sports car who in truth is hurtful to women.

People who decide to use JavaScript outside of the browser are backwards: the browser should acquire a good language, instead of the worst language contaminating the entirety of computing.

The real reason every other language compiles to JS, and the real reason WASM exists, is not a lack of cool new features in JS. The real reason is that in JS, this is broken, function is broken, arrow functions are broken, super() is broken, the type system is broken... To learn JS is to learn a pointless list of exceptions to expected behavior.

Consequently, many developers choose to use languages that compile to JavaScript or explore alternatives like WebAssembly. This trend highlights a critical issue: JavaScript's fundamental flaws hinder development efficiency and cost lots of time and money.

As an example, here is a lesson for today:

Arrow functions cannot be constructors.
Arrow functions do not inherit a this binding; if they are part of an object, they cannot talk to it.
Arrow functions don't provide arguments; normal functions do.
Named functions are hoisted, const is not. Arrow functions were invented to be anonymous and to make small event handlers and callbacks, but people are abusing them and naming them with const.

This is just one confusing instance where JS has 2 ways of doing the same thing, both with advantages and disadvantages depending on what you are doing. How much of this will you remember in 30 days?

Why not pick a good language instead?

In short, what needs to change in JavaScript is its WAT. And while that doesn't happen, hordes of young programmers are learning a horrible programming language first. Getting used to the most inelegant solutions. Honestly, JavaScript has become the most popular programming language, and also the worst popular programming language. The only things that are worse are those that are designed to be worse: esoteric programming languages like INTERCAL and Whitespace.

But the worst part is, they seem to have given up fixing JavaScript. They have concluded it's impossible, due to the requirement of eternal backwards compatibility. That is the wrong conclusion, and it shall be revised real soon now, as web development has clearly become unsustainable.

2. Ignoring those problems like ostriches

Most JavaScript developers are the proverbial boiled frog. They have been studying this cursed language for years and years, why worry now? "I am productive in JavaScript in spite of its shortcomings." Their attitude is that of the ostrich: "learn the good parts", shun the bad parts, and develop code today.

They will add, that all the alternatives to JavaScript are also doomed, for other reasons. Maybe they are harder to debug in the browser. Their performance is necessarily worse than JavaScript, since they compile to JavaScript. And so on.

In short, it's the famous Sunk Cost Fallacy. JavaScript is evidently not beneficial, but one sticks with it due to past investments.

Where Python 3 focused on removing all the warts from Python 2 and succeeded, people imagine this to be impossible in JS, since they believe there is an eternal backwards compatibility requirement. I predict this requirement will drop very soon, as the accumulation of horrible web standards becomes a terrible burden.

Yet, a successful precedent exists: ActionScript 3 introduced class-based inheritance, separate from, and without disrupting, the existing prototype-based system. This demonstrates that it's feasible to evolve a language without breaking existing code.

Again: It is NOT impossible to fix JavaScript; the impossibility is an illusion that makes you accept JS.

The only thing that is even more painful than fixing a floor full of rusty nails pointing up... is to forever tolerate it. But that's exactly what a boiled frog does. "I already know where the rusty nails are, I don't step on them anymore."

This almost amounts to a Human Rights issue.

My advice to you is: are you writing a large web app? Then for the love of humanity, do it in anything but JavaScript.

3. Problems with TypeScript

There is a moderately popular project by Facebook called Flow. It lets you write static type annotations on otherwise JavaScript code, it checks the types as you write, and then it simply removes the type annotations in the end, leaving only your JS code. I consider Flow a good design – if you need to write JS, that is.

Microsoft answered the same question differently.

They hired Anders Hejlsberg, the guy who had created Turbo Pascal and Borland Delphi, to make derived languages for them. First they used him in their attempt to Embrace, Extend and Extinguish Java. Microsoft then lost a tremendous lawsuit to Sun Microsystems for that misstep, so they turned to the next best war strategy: make their own Java while denying all influence. Thus C# and the Dot Net Framework were born, or rather, cloned. To this day these people are affirming that "C# belongs to the C family of languages", while it really is Java with a couple of misfeatures removed. Hejlsberg was and is the main designer of C#.

In 2012 Microsoft announced another Hejlsberg creation: TypeScript, which has become the most popular compiles-to-js language. But instead of just adding types to JS (like Flow does), it is a bastard child of JS and C#. I imagine they gave Hejlsberg these contradictory goals: "We want C# for the web, but it also must be a superset of JavaScript". The superset bit means, if you paste JS into a TS file, it just works – all JS is valid TS. It also means TS has its own separate features, augmenting JS.

The fact is, this one-way compatibility with JS is probably why TS won. But you know what I am going to say, right?

TypeScript again decides not to fix any of the bad parts of JavaScript. TypeScript is a monstrous creation, it adds even more cool features, such as algebraic types, without first fixing the basics. The decision to be a superset of JS sealed TypeScript's fate; after that decision, being a good language was impossible. It presents the best language features and the worst language features in a single thing. TypeScript is the most hypocritic programming language in the world, and as such, it could only have been born at Microsoft. Or Oracle, Apple, Facebook or Google.

Learning TypeScript is learning tens of weird unexpected syntaxes in the type system – things that should be natural and much easier – and then forgetting them while you are coding.

Every developer has noticed that, if TS seems powerful, it is because there's an enormous amount of features for annotating types. It's not simple at all, it amounts to a tremendous cognitive burden. And newer versions never simplify anything, they only add to that burden. The developers of TypeScript take too much freedom to make it impossibly complex. I have found this frustrating, and I am not alone:

Rich Harris: "We also eliminate an entire class of annoying papercuts that will be familiar to anyone who has worked with the uneven landscape of TypeScript tooling."

Here is a video detailing the latest TS release. And here are some YouTube comments sharing my sentiment:

@tacochub4353: These updates are neat... sure, but I don't really see how these methods solve the plethora of issues with using TypeScript. All they seem to do is add unnecessary complexity to an already perplexing ecosystem filled with syntactical nuances.

@JamesDSchw: My beef with many TS releases over the years surround the cognitive load they incur - more syntax and language semantics to be able to model types in existing libraries in the ecosystem.

@universe_decoded797: Typescript solving things that are not problems to create more problems is problematic. ‘Simple things are hard to create’ is a true statement.

In short, you wanted to fix JavaScript and suddenly you saw TypeScript. It overloaded your senses with so much information and impression of power, that it seemed to be the right solution. The only thing everyone forgot was the actual problem: we need to fix JS.

To choose TypeScript, one must overlook two facts:

There is tremendous value in keeping language scope down to a minimum. Until Python 3.4 more or less, Python was a small language, any programmer could pick it up in a week by reading a 100-page description of the language. And then they could learn crucial parts of the standard library in a couple of months. One would become productive very quickly. Unfortunately, Python has entered a new phase, in which they forget the value of staying small and keep adding syntax. Becoming Scala, a language that one never finishes learning. If you are a Scala programmer and you start reading another developer's code, chances are, you have to stop and look up this syntax that is new to you. That is a horrible mistake. Back to TypeScript, it starts by accepting JavaScript, but then paradoxically it again becomes Scala by relentlessly adding features.
We need a language that is a solid base to build upon; the perplexing crumminess of JavaScript is automatically unacceptable if mental health is a value.

4. Problems with functional languages

It is currently my opinion that an object-oriented programming language is perfect for creating user interfaces, even a pure OO language such as Smalltalk.

But here, let us ponder that an object-oriented approach greatly benefits from adopting a few lessons from functional languages. Functional programming is not the opposite of object-oriented programming; to a certain extent these can be combined. Also, object orientation today accepts that composition is better than inheritance most of the time. I favor a pragmatic approach that uses notions from both these worlds. Immutability only on certain kinds of information, and a conscious effort to create pure functions and unit tests for these – these are key to writing good code.

But the current wave of functional programming languages is another thing that a healthy reader should doubt. In about 15 years of people trying functional languages and immutability in the browser (either in JS or in functional languages such as Elm, Elixir and ReScript), the functional paradigm and the insistence on immutability have failed to deliver the cleanliness and developer productivity that were promised.

Here are some arguments so we can establish that functional languages and techniques are not the panacea:

Complexity in state management
- State overhead: Functional programming emphasizes immutability, leading to frequent state copies. This can increase memory usage and overhead, unless the collections in the language are carefully made to avoid this problem (such as in Clojure).
- Verbose code: Functional paradigms often require more boilerplate code to manage state changes in an immutable manner compared to traditional imperative approaches, unless this is addressed in the language design (such as in Clojure).
- Business Logic Complexity: For complex business logic, imperative programming often provides more straightforward solutions, whereas functional programming can lead to overly abstract and convoluted code. Unless the language is data-centric (such as Clojure).
Steep learning curve
- Conceptual barrier: Functional programming concepts like higher-order functions, monads, and pure functions can be difficult for developers to grasp, purity being the easiest. Mathematical concepts are of course beautiful in computing, but they simply are not the way most people communicate – and the web should be for everyone.
- Limited adoption: The steep learning curve has hindered widespread adoption, making it harder to find developers skilled in functional programming, which impacts team productivity.
Performance concerns
- Inefficiency in browsers: Functional programming can introduce performance issues in the browser, such as excessive garbage collection due to frequent object creation from immutable state changes.
- Lack of optimization: JavaScript engines are primarily optimized for imperative code, potentially leading to less efficient execution of functional code.

While above I have tried my best to talk ill of functional languages… knowing what I know today, to develop user interfaces, I would reach:

first for a functional language that is conscious of, and addresses, the pitfalls above (such as Clojure);
then for a multi-paradigm expressive language such as Python, Dart or Kotlin;
then for a pure OO language such as Smalltalk;
then for a hybrid functional language such as ReScript, OCaml or F#;
then for an opinionated, pure functional language such as Elm or Haskell;
then for anything else in existence;
before resigning myself to use TypeScript or JavaScript with their broken basics.

5. Dart as a solution

In 2009, Node.js brought JavaScript to the server, and now boiled frogs write their backend and frontend in the same language: the worst one. Someone help them!

Seeing this, Google unveiled their Dart language in 2011. You can think of it as the last Java clone, this time with better influences. Dart 1.0 came out on November 2013.

The initial plan for Dart was to include it in Chrome as a second native browser language, the good brother of JavaScript. This was criticized for fragmenting the web, so they gave up this idea in 2015 at the release of Dart 1.9. And then Google proceeded to dominate the web anyway – through countless bad standards – such that now it is financially impossible for anyone else to develop a new browser. We might as well have had Dart in Chrome, it would have been a tremendous blessing all these years.

There exists a parallel universe in which the frontend community gladly accepted Dart as their saviour when Google proposed it as a sane, parallel native language in the browser. I wish I lived in that universe. Frontend devs, you have Stockholm Syndrome.

Instead, Dart was sort of forgotten for a couple of years while Flutter was being developed. It was released in 2018.

Here are reasons why Dart is good for developing applications and GUIs:

It has none of JavaScript's defects.
It is essentially just another boring multi-purpose Java clone with a few saving graces.
It has null safety.
It has a good, pragmatic type system without any trace of TypeScript complications. Something that just helps programmers instead of stealing their attention.
It has garbage collection.
Very performant for a garbage-collected language. You can roughly think of Dart as 10 times faster than Python and 10 times slower than C++.
It runs on every platform; it can also compile to JS.
It is now beginning to compile to WebAssembly and even use its garbage collector – this makes the runtime smaller.
It is being developed at a nice pace.
It has a moderate, good enough syntax size; it does not seem to want to become Scala.
It has features to write constructors without so much boilerplate, making Java look silly. However, Python is still better in this regard.
In fact, in some places it has been smarter than Java and C#. For instance, it does not have the private, protected and public keywords; instead, the programmer simply starts a variable name with an underscore (such as _myVariable) and that makes the variable private to the current file. This is great language design, removing lots of noise in a single movement.
Developer productivity and comfort are higher in a no-nonsense, immediately familiar language.
If you learn Dart, you are learning the language of Flutter. If you write the core of your web app in Dart, you can later reuse some of that core in a mobile app. And Flutter is much better than React Native... because React Native is based on JS/TS, and its misarchitecture consists of letting you use crummy web technologies such as CSS (or rather, just an arbitrary subset of these technologies) which then get translated into native widgets. It is just a fundamental lie, designed to keep web developers in their narrow comfort zone.

6. Problems with Dart

Metaprogramming/reflection is currently weak in Dart, but being worked on right now (2024), with macros in the roadmap for the next few releases.
Interop with JavaScript is more difficult than expected. Using a JS library in Dart code is fine, but you have to write typing stubs for the library's interface. Consuming Dart code from JS requires you to expose objects and functions with a decorator, and I don't think you currently can expose them in a JS module, so you have to put the API on the window object, which feels outdated.
Indentation with only 2 spaces is hard to see.
It uses curly braces instead of significant indentation. (Significant whitespace is objectively better because it communicates the same information with less visual noise and occupies fewer lines.)
It requires semicolons.

Given the above, I would definitely write web apps in Dart, especially using its numerous frameworks for doing so; I would also write a large app component to be consumed by JS through a relatively small interface; but I would not write a typical JS library in Dart, unfortunately.

7. Conclusion

Going parallel to JS is unavoidable, that is why everyone wants Web Assembly to succeed: it's the only escape.

Dart is not perfect, but programming in it is bliss compared to JavaScript and TypeScript. There are alternatives out there; your responsibility is to choose something better than what everyone else is using, if you are smart.

8. Futurology

The feared web fork is soon going to be required, and for all Web tech, not just JavaScript. Because the powers that be have introduced an enormous number of spectacularly failing standards:

JavaScript
HTML that is not XML
CSS, which again is growing impossibly as a language, is impossibly complex in the interaction of its features, contains an impossible number of footguns, and is already humanly impossible to learn for its target audience of designers and common people
Web Components (Custom Elements), which are enormously complex, have a terribly verbose API, yet somehow manage to fail at addressing basic concerns of writing GUIs
IndexedDB, the only way for frontend devs to access a SQLite database, has a horrendous API, so nobody uses it
...?

The idea that these bad standards, plagued by complexity and inconsistencies, must remain in the Web forever for backwards compat is absurd and impossible. Of course one day this entire mess will be dropped.

The web platform has become so convoluted that only tech giants can afford to build browsers. This centralization of power threatens the open nature of the web.

When Firefox finally finishes failing, we'll be in the impossible situation of every browser being based on Chromium. This is due to the number of incredibly complex features and standards that a browser must implement. Thus the web no longer belongs to the people, it belongs to tech giants.

I am calling this right now: soon the people will create a "New Simple Web", from scratch, with simpler (but not necessarily more powerful) technologies, languages and protocols, to replace this Impossibly Big Ball of Backwards Compatible Spaghetti. This revolution will be painful in many ways, but it is clearly unavoidable. The most important values for the right technologies, languages and protocols will not be power, but cleanliness, simplicity and developer experience.

I believe the New Simple Web will look more like Flutter than anything else. It will be based on a single good language. No separate language for formatting. It will tend to the pragmatic needs of writing applications. But it will still somehow make contents public, as they are today. Oh, and it will have no DRM.

In order to become popular, the New Simple Web will have to offer something to the users, too. Evidently, that something will be their freedom. By then Google will already be the distopian oppressive OCP they have decided to become, so they will be closing everything on the Web: mandatory ads, mandatory privacy invasion, mandatory taxes, mandatory DRM protecting THEIR content which they actually stole from books, poorly paid videomakers etc... you name it. This is what Chrome will be.

Other tech giants will try to create an Alternative Web in advance, but they will not provide the necessary freedom, and therefore they will fail.

Someone will rise to the challenge, present a clear picture of how the New Simple Web should be built, and do it. People will use Chrome for banking and gradually migrate to the New Simple Web for everything else.

And then the cycle will begin again, inasmuch as humans are bound to forget learned lessons.

You're too quick to dismiss Agile

Nando Florestan — Sun, 07 Jul 2024 12:00:00 GMT

I see too many programmers today thinking that Agile is nonsense. It has even become an opportunity to sell books on esoteric methodologies.

However, there's widespread confusion:

about what Agile actually proposes,
about how bad the alternative is,
about what our personal experience really is – usually with Scrum.

First of all, let's quickly remember what Agile really is: a reaction to Waterfall.

I have another post that defines Waterfall and begins to explain Agile as a reaction to it. You should start there; maybe that's where the confusion will vanish.

The manifesto

Please refer to the original Agile Manifesto, which is about 5 lines long:

https://agilemanifesto.org/

It simply means that:

processes and tools are important, but individuals and interactions are more important.
comprehensive documentation is important, but working software is more important.
contract negotiation is important, but customer collaboration is more important.
following a plan is important, but responding to change is more important.

You see, it's extremely hard to disagree with anything the manifesto actually says.

For example, notice how the manifesto didn't prescribe any meetings. The meetings that developers complain about so much are usually the Scrum meetings. Therefore, they are not a part of Agile itself. One can develop software well while organizing one's meetings in a different way.

But what some programmers really want is to develop software without communicating at all; that's impossible, and therefore, their own mistake.

Scrum

Scrum is a modern development methodology, appropriate for developing products of any kind, not just software. Scrum does not actually say anything specific about software development.

However, it prescribes a set of meetings. If you don't have your meetings that way, then you are not doing Scrum, you are doing something else. We just saw that Agile values individuals and interactions over processes; therefore each team should have sovereignty over their meetings and should only do Scrum meetings if they think that's appropriate for the specific team. Therefore, Scrum is already not following Agile in principle by demanding those meetings – although the ideas in Scrum can be employed in Agile!

The meetings in Scrum do address a tendency that software developers have, to not communicate enough (or sometimes at all) between themselves. If left unchecked, this tendency is enormously dangerous to the health of any project. We'll talk about this again below (XP).

The Scrum Guide (2009-2020) is another document that is very brief (12 pages) and easy to read. Again, you might be surprised at the things it doesn't say. For instance, Kanban and Planning Poker are not necessarily a part of Scrum. Scrum does not prescribe how the product backlog should be organized or how the team actually decides what to include in the next sprint. You might be surprised at how democratic it really is, if you read it.

I have worked in several bad Scrum implementations, each with their own troubles. However, I do know from experience that Scrum can work wonderfully well, because I have been part of a good Scrum implementation. Its democratic nature kept the entire team quite enthusiastic about their work.

Scrum is a humanistic revolution in the workplace. It inverts the hierarchy. If in the 80s you had quite bossy bosses bossing workers around, Scrum says, bosses are out. Scrum teams have no boss; there is only a facilitator, who is supposed to give workers freedom to do the work the way they want to do it. The role of the facilitator is actually to help the workers, for instance by removing obstacles (institutional, physical etc.) that hinder their best work. This creates an engaged team where before you only had begrudging employees. The Scrum team is self-managing.

"But in my experience Scrum is a tool of domination", you say. Well, did you experience actual Scrum, or a bastardized "version" that actually contradicts its principles?

If you are going to criticize Agile or Scrum, first understand what each actually says. Most often, you'll realize your trouble is with the implementations you've had the misfortune of experiencing.

If you pay attention to the history of Scrum, you realize there are at least 2 Scrums:

The 1986 one, from the paper "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka;
The famous one, from Schwaber and Sutherland in 1995. Both authors are also signataries of the 2001 Manifesto for Agile Software Development. But the Scrum Guide only appeared in 2009.

It is important to notice that the lineage of thought is different for Scrum – it originated in Toyota, not in software development. Quoting the above Wikipedia article about the Japanese original Scrum:

Based on case studies from manufacturing firms in the automotive, photocopier, and printer industries, the authors outlined a new approach to product development for increased speed and flexibility. They called this the rugby approach, as the process involves a single cross-functional team operating across multiple overlapping phases, in which the team "tries to go the distance as a unit, passing the ball back and forth". The authors later developed scrum in their book, The Knowledge Creating Company.

What I can see Scrum has in common with Agile is the humanistic aspect:

individuals and interactions over processes and tools
collaboration over negotiation – this time within the team.

Extreme Programming (XP)

XP is the actual first Agile methodology for software development specifically. This is the one that was made by programmers, for programmers. It was developed by Kent Beck and his team from 1996 to 1999, when he wrote Extreme Programming Explained. That team included these guys who also signed the Agile Manifesto:

Kent Beck, inventor of XP
Ward Cunningham, the inventor of the wiki
Ron Jeffries

Most of the ideas in the Agile Manifesto are already found in XP.

XP described most of the software development practices that won and are in use today:

writing automated tests and using them to get the courage to refactor existing code freely, without worrying about breaking everything
refactoring before implementing a new feature, so it becomes easier to implement
delaying decisions when possible
pair programming to improve team communication, disseminate knowledge amongst team members, and to severely improve code quality, killing bugs immediately
writing only documentation that you actually need and can keep up-to-date

XP was revolutionary, especially when compared to Almighty Thud methodologies which emphasized writing lots of documentation, which were the norm in the Waterfall era. (The Almighty Thud is the name for the noise made by the volume of paper documentation hitting one's desk.)

In fact, XP is still revolutionary, inasmuch as you haven't yet personally practiced its propositions.

Software is a tamagotchi

The main conflict I see in software development is this: Agile promises continuous delivery of value (something like delivering features all the time), but software development simply isn't like that.

Expecting a development team to deliver only features all the time is as realistic as expecting a human being to be of service to their significant other all the time. The reality is, the human and the team need some time to themselves.

Business people start with this idea that software is a project with a beginning and an end. "I will develop an app, then sit back and profit." Nothing could be further…

Reality is like Chacon said:

Software is a tamagotchi. It has its own needs, that must be tended to.

The problem is, business people cannot see the virtual pet or its demands, if they cannot program. A programmer can try to explain it to them, but they get bored quickly.

This tamagotchi is a mythical creature. Only little children can see E. T., grownups cannot. And only developers can see the needs of the software; they are invisible to the marketing team.

This past week I upgraded packages in our Linux servers because of the recently discovered openssh vulnerability. If you have servers, you have to be on top of security, there is no alternative.

— Yeah, but as a business person, I absolutely CAN see the value and importance in that work, since not having our users' passwords stolen is a major component of their satisfaction.

Okay, then I suppose sometimes you can see the tamagotchi demanding we do things that our users are completely unaware of.

Let me try another example then. We really have to do some work on the way we use our asynchronous queue system. You see, things like sending emails, talking to external APIs, anything that isn't instantaneous... these things are done in separate processes, in a queue. That queue is known as FIFO, which means First In, First Out, which means first come, first served. The queue is a buffer for tasks that the app needs to do. But the queue has certain features that we need to start using in order not to have problems in it, which would be a terrible situation.

— That's too technical for me, you seem to be saying words. If I were to prioritize that work, I think I would actually never prioritize it, I think, because I have features that our users actually want, and those I do understand.

…and this is an example of the virtual pet dying of starvation, because the parents didn't understand its importance.

Technical debt

It is a terrible thing, when instead of the whole team choosing what needs to be done in the next sprint, it gets dictated by a non-technical Product Owner who leaves technical debt on the wall forever gathering spiders' webs, until it falls on the ground and gets swept away by someone who doesn't think they are important.

A good rule for solving technical debt had already been proposed in XP: refactor before you implement a new feature. This means, remove the technical debt that affects the feature you are about to implement. It also means, leave alone the technical debt that does not affect the code you need to change. Some technical debt exists in code that never gets changed, and that is okay if the code is working fine.

By the way, bugs are not technical debt, bugs are bugs. Bugs annoy users, technical debt "only" annoys developers. Generally, solving bugs is the most important priority, because if you leave bugs alone, they start compounding. Then when you finally decide to kill them, you can't tell anymore where one starts and ends, because they have become this multi-headed monster. Nobody can understand the behavior of a buggy system; a sane mind can only understand sane behavior.

However, annoying developers is a terrible thing too, and that is what business people don't understand.

Clean code

There's a second document about Agile, also very brief, which tries to clarify the Agile Manifesto. It's the 12 Principles behind the Agile Manifesto. Again I invite you to read them.

Here's a bit I would like to emphasize:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility.

This means, agile is not supposed to be a tool against developers. This means the maintainability of the code is valuable, and important to agility.

Any psychologist will tell you, before you can love other people, you need to actually love yourself.

As a developer, each day you must do something to improve your own life. Nobody else is going to do that for you. They will even have difficulty understanding that an annoyed programmer is a much slower programmer, naturally and for good reason. It's hard to put something in production when you can't get past development.

Martin Fowler, a famous and respected British author who writes the best descriptions of ideas in software development, while offering the sanest opinions, went through the trouble of cataloguing and describing the various refactorings, in his famous 1999 book Refactoring. He is also one of the first signataries of the Agile Manifesto.

Why would he write Refactoring if technical debt were not important enough to fix???

Oh, and here is his description of technical debt.

Robert C. Martin, a very important author whose name you also find under the Agile Manifesto, is sort of saying the same thing, when he says, the only way to go fast, is to go well.

A large application cannot be built without lots of discipline. A mature programmer knows this and takes pride in the discipline, just like a practitioner of martial arts or a musician.

Robert C. Martin, in fact, goes beyond the XP rule. He notices that people are about to start dying due to badly written software, or maybe already are dying. So he says, when the thing works, do not stop and deliver it. When the thing works, you are only half done. Now you have to clean it up. Remove all the technical debt, make it easy for other programmers to understand. Make it easy even for you yourself to understand it after 2 months! Remove the useless tests, finish writing the good ones. Refactor the spaghetti, rename the badly named functions. Treat your program like a poem.

If the company places excessive pressure on developers, it is an engineer's duty to be firm and say no, especially if people's health is directly or indirectly at stake. This is the ultimate test of a true professional. You do know that "I was just following orders" does not convince. Show some character strength when your turn comes.

If developers do not self-police in this way, people will die due to buggy programs, and then the legislators will legislate software development, and the result will be much worse. This is what Martin says, and it's hard to disagree.

As a developer, do love your users, but love yourself first. You can't be of use to your users, or the company, or your family, if your software becomes unmaintainable.

In other words, no matter how much you love your user, you can't be used by him all day long!

When a musician gets popular, she often needs to put her foot down and say "no, only 2 shows a week maximum and that's final". Otherwise there's no time to hone her craft. These companies always want you for what you already know, but never want you to spend any time learning what you need to learn to stay relevant. It's up to you to draw the line.

According to Woody Zuill, teams and managers should spend the time to make the work easy to do.

Allen Holub has a heuristics page in which he briefly explains agile in his own words. At the time I am writing, number 15 reads: "Quality is not negotiable. (This rule applies to all aspects of quality, not just testing.)"

Conclusion

When bad managers use Scrum against developers and basic development needs, that is in fact against Agile principles.

A solution for our woes will be found in a proper implementation of Agile ideas – not in mistakenly escaping those ideas as if something better existed out there.

Mind the gurus you choose. Digital influencers can be entertaining and arouse emotions, but some of their advice is terribly misguided. To them, all the names in this article are preferable.

Risks of adopting Flutter

Nando Florestan — Thu, 23 May 2024 09:51:00 GMT

My previous post ended by recommending "something like Flutter" against the crumminess of web tech. But it is not that simple.

First of all, Flutter's performance on the web is much worse than on the other platforms it supports. And this year (2024) this is not going to change because the Flutter developers said they are not working on it right now.

That is enough to rule out Flutter on the web, I think. But suppose that weren't the case. Here are more thoughts about it.

The argument against Flutter

Google kills its projects without mercy. The Google Cemetery website lists tens of such projects.

It is about this risk that David Heinemeier Hansson wrote something I have to quote in its entirety:

The saying "nobody ever got fired for buying IBM" is at its essence about risk management. The traditional wisdom goes that if you buy from a big company, you're going to be safe. It may be more expensive, but big companies project an image of stability and reliability, so buying their wares is seen as the prudent choice. Except, it isn't. Certainly not any more. Meta killing Workplace is merely exhibit #49667.

Any company that hitched their wagon to Workplace just got served with an eviction notice. In a about a year, the data will go read-only, and shortly after that, it's game over. Now companies from Spotify to McDonalds, along with millions of others, have to scramble to find an alternative. Simply because Meta can't be bothered to maintain a platform that's merely used by millions when their consumer business is used by billions.

This, right here, is the risk of buying anything from big tech like Meta and Google. Their main ad-based cash cows are so fantastically profitable that whether it's the millions of paying accounts on Workplace or the millions of live websites once hosted by Google Domains, it all just pales in comparison, and is thus one strategy rotation away from being labeled "non-core" and killed off.

Buying from big isn't the sure bet they want you to believe. Buy from someone who actually needs your business to make the wheels go round.

How can you be sure Flutter is going to stay around? If Google dropped it, I doubt the open source community would be able to maintain it, just because it is a project that targets many platforms and requires many different kinds of expertises. It definitely would require professional organization similar to the Linux kernel or things like Gnome and KDE.

Arguments in favor of Flutter

If you follow DHH's advice and choose something from smaller companies, guess what, many of these aim to be bought, and then the rug gets pulled from under you anyway. If Microsoft buys the product, it starts to get worse with each update. But normally the product is bought to be killed. So the risk must be managed taking much more into account than just company sizes.

The price of Flutter is right for everyone. (Zero.) Xamarin used to offer a comparable product for cross-platform development which cost a thousand dollars per developer per year. And then Xamarin was bought by Microsoft and the product was included into Microsoft's own.

Cross-platform development solutions being offered by smaller organizations (that I know of), such as Qt and kivy, do not seem to be equal in scope.

I should also clarify that Flutter is NOT a toy. The most recent figure is that one million applications have been built with it. That is a very significant number in the mobile space. No other cross-platform toolkit has that number.

Incredibly relevant to the question of "what tech to use" is the advice given in the famous article "Beating the Averages", by Paul Graham, which you absolutely should read in its entirety. Nevertheless, I will quote:

We knew that everyone else was writing their software in C++ or Perl. But we also knew that that didn't mean anything. If you chose technology that way, you'd be running Windows. When you choose technology, you have to ignore what other people are doing, and consider only what will work the best.

(...)

When I was about nine I happened to get hold of a copy of "The Day of the Jackal", by Frederick Forsyth. The main character is an assassin who is hired to kill the president of France. The assassin has to get past the police to get up to an apartment that overlooks the president's route. He walks right by them, dressed up as an old man on crutches, and they never suspect him.

Our secret weapon was similar. We wrote our software in a weird AI language, with a bizarre syntax full of parentheses. For years it had annoyed me to hear Lisp described that way. But now it worked to our advantage. In business, there is nothing more valuable than a technical advantage your competitors don't understand. In business, as in war, surprise is worth as much as force.

Graham's weapon, the Lisp language, was not and still is not normally used in businesses. It is mostly used by academics. Nubank using Clojure (a lisp language) is a notable exception. (And Nubank's app is made with Flutter – they must be following Graham's advice.) But the main point is, don't do what everyone else is doing – do something better, which I think Flutter is, except for the Google risk.

Perusing discussions about the future of Flutter, I came across this comment from July 2023 that made a lot of sense to me:

Connecting the dots of what Google has been doing over the past 13+ years:

Launched a system programming language called GO
Forked little kernel to make Zircon
Started the Fuchsia project on top of Zircon built with Go.
Launched Flutter for cross platform
Community engagement for spreading the usage of Flutter
Build all tool kits for complete cross platform support
Build a large swarm of one million apps running in Flutter on play store by community

So I believe Google is trying to hit the IOT market as the existing operating systems are very heavy to be interfaced with smaller devices in which Zircon based hardware is a lighter option with a lot of perks. To make that hardware accessible to masses we need an operating system which is the Fuchsia. But if an operating system is introduced to the world no one is going to use it as for the adoption we require APPS. To make those apps they selected Flutter and Dart as their native language to write apps for Fuschia. Now, they've started community engagement to make flutter a widespread tool and used community to make a unified codebase for a million apps which can be made available in both the play store and the upcoming Fuschia store. This will solve the problem of NO apps in the market for newly launching OS. (The Windows Phone team thought people would make apps instead of community engagement through the years that's why they failed miserably.)

Now when the new OS is launched it'll have a lot of apps which can simply be ported to support Fuchsia with minimal efforts and opens a whole new world of Zircon based hardware hitting the market interfacing with the new OS ushering a new era of IOT apps through Fuchsia.

So Flutter is just a part of a BIG PLAN for years and not a thing made to Die by Google.

That's all I have for you. I think Flutter is the way forward for me, but unfortunately I don't have a crystal ball to divine the future.

The crumminess of web tech

Nando Florestan — Mon, 20 May 2024 10:59:03 GMT

We make things for the web because the web is free. We want our stuff to be accessible to everyone. We don't want, for instance, the Apple police dictating whether we can update our app or not, or when, or how, or taking an enormous cut of our income.

But the default web tech has always been very bad for making web applications. It was originally invented for hypertext, not apps. It has been a long "evolution", but until yesterday, it didn't even offer native popovers, so everyone had to create their own. It is safe to say that a popover component should be part of every basic app toolkit.

Here are a few ways in which web tech is bad:

1. JavaScript

JavaScript is a language that makes kittens cry every day. It was created in a week and now we have to tolerate it forever!? WAT. The best book about it is called "JavaScript - the good parts"... It is the only language I know with so many evil parts, other than INTERCAL.

2. Standards schmandards

Web browsers implement standards differently, and devs suffer with browser support. This will never improve: the new Popover API, which everyone wants to use, already has been implemented differently in each browser. In 2024! My God, the story never changes!!!

Therefore your layout breaks through no fault of your own. It may work today and break tomorrow – not in theory, but in practice.

Further, when your web app runs out there in weird browsers on weird phones, or just in Safari (which is always lagging like an Internet Explorer in adoption of web standards), you keep seeing very weird error messages in your Sentry. Hard to believe they are real.

3. CSS

CSS is always in flux. At first, one had to learn how to write semantic CSS. Then CSS frameworks appeared, solving new problems and creating new ones. Now everyone uses Tailwind, which is again better, but again poses the old problem of how to use CSS well. In fact, Tailwind requires the development of very good taste about "where to put this code", because there are 4 different layers of abstraction, all of them valuable:

global CSS (such as theme variables),
components (where Tailwind defers to Bootstrap style),
usage of actual Tailwind classes (with the danger of too much repetition), and
inline styles, which should be very rare, but still do happen.

4. Build pipeline hell

Typescript and Flow are better than JS, but using them requires compilation. Tailwind does, too. Build tools such as vite are hard to understand and configure, but occasionally that responsibility falls on you. At that moment, you wish you had chosen straight JS, no build pipeline.

For instance, this article teaches you how to have hot reload if you use Vite in the frontend and Flask in the backend. It doesn't mention that you can do the opposite: Vite has a reverse proxy. Maybe the article was written before Vite added the reverse proxy. Anyway, the section named "A word of caution" states:

In my 7 years of building for the web, I've used Grunt, Gulp, Webpack, esbuild, and Parcel. Snowpack and Rome came-and-went before I ever had a chance to try them. Bun is vying for the spot of The New Hotness in bundling, Rome has been forked into Biome, and Vercel is building a Rust-based Webpack alternative.

5. Overactive ecosystem

The above paragraph is just one instance of a tremendous problem:

The JavaScript ecosystem is overactive, oriented to excitement, with lots of packages being created all the time, and then dying in less than 5 years. In fact, you will have a library die before you have a chance to use it. Happened to him, happened to me. A normal developer needs something durable, stable. But we are unable to tell which tools are going to be responsible and stay maintained. And the considerable force of the FOMO makes us try many alternatives.

6. Unruly npm dependencies

Controlling the dependencies of your project can be pretty impossible. Every medium project out there depends on an unreasonable number of npm packages, and you as app developer have a very faint idea of what most of them do. This is dangerous. But it is also a consequence of the overactive ecosystem.

7. Legacy code

Because libraries and frameworks are so short-lived, they put a ceiling on how much devs can accomplish before they have to reimplement their own "legacy code". Witness Angular 2.0, which infamously gave devs no upgrade path from AngularJS 1, leaving thousands of projects orphaned.

8. Boiled frogs

Because the web is necessary, programmers learn JavaScript first and specialize in it too early. These inexperienced developers easily become the proverbial boiled frog – they have no idea of what a sane environment actually feels like, let alone a good programming language. They think that world is normal.

Boiled frogs will disagree with what I am saying. Perhaps even jump to the cheap accusation of a "skill issue".

A subset of the boiled frogs shrug and declare "I did my job". They are happy to learn something new, jump ship, and leave the hand that fed them with legacy code that is only 4 years old. That is an irresponsible and immoral thing to do. Those people have no right to complain about planned obsolescence, or they would be hypocrites.

On the other hand, developers who have a clue may dismay in the face of adversity, sometimes optimizing for ease of implementation rather than awesomeness of UI design. Today many a developer says they prefer the backend to the frontend.

If HTML, CSS and JS weren't so awful, then we wouldn't be seeing every other language compile to JS or WebAssembly or both. The impetus of WebAssembly is proof that many, many people agree with what I am saying here.

9. Too much learning

And now the worst part: the amount of learning that a programmer has to constantly go through. This is something that the boiled frogs don't see anymore, but they have been wasting their lives and brains on HTML, CSS and JS, not to mention JS frameworks in general, especially React, Vue etc. which are always imposing new concepts and new ways.

FOMO makes you try new frameworks. For instance, SolidJS suddenly offers much higher performance through a smarter observable. But only when you use it, do you realize limitations such as... SolidJS only likes arrays, you can't use Maps or Sets, which by the way are collections in JS that should be much more popular.

99% of JS frameworks are full of leaky abstractions like that. They seem to solve a problem but create many others by hurting all the other dreams you had for your code.

Tiny history of the crumminess

In 1995, Netscape told Brendan Eich to quickly create a little language they wanted to add to their browser. So JavaScript was created in 10 days. Nobody expected it to become the most used language...

Through the decades, many, many alternatives were created, so developers wouldn't have to suffer the crummy JavaScript. One of the most important ones was CoffeeScript (2009). Microsoft hired the designer of Delphi to create their own in 2012: TypeScript, or "C# in the browser". TypeScript basically has won. However, all these languages introduce a compilation step, because only JavaScript ran in the browser. Now developers have to wait before seeing changes on the page, which is crummy.

The formatting language, CSS, was considered crummy, so they did the same thing: they invented CSS improvements which needed a compilation step down to CSS, making the total compilation time even longer and crummier.

With compilation, debugging suddenly became crummy, because when an error occurred, the browser reported the error was in line 934 of a JavaScript program that you hadn't written and looked hideous. So Chrome invented source maps, solving that problem: Now the browser would map lines of code and report the error on your CoffeScript source, not the translated JavaScript source. But source maps are a heavy download and they take even more time to compile, making them crummy. For being heavy, they are never used in production.

Trying to control the problem of web apps being heavier and heavier downloads in production, they added "tree shaking", which means, the compiler is smart enough to omit functions that were written but aren't actually currently used in the app. Feeling smart, they forget this is one more complicated thing that every web developer needs to know exists, and takes more compilation time, being, therefore, crummy.

To give back to developers the immediacy of saving code and seeing the changes in the browser without having to wait, sophisticated build tools such as gulp, webpack, vite etc. make complex decisions about which of those things to do during development and which to do in a production build. That's not all they do, it's more complex. Anyway, they have become yet another essential tool in the toolkit, they last even shorter than web frameworks, they are hard to understand, they have hundreds of configuration options... but they solve the immediacy problem – yet again, in a crummy way.

And in this manner, web development is ever more complex, and the crazy mob continues to think themselves smart after patching fundamental wounds with more and more tools.

The real solution always was something like Dart (2011) or WebAssembly (2017): a hard break with crummy web tech, as long as the replacement tech were as open as the web, and designed for applications from the start. So what did the boiled frogs do? They basically ignored these. The initial plan for Dart was to include it in Chrome as the good brother of JavaScript. This was criticized for fragmenting the web, so they gave up this idea in 2015.

Instead, Node.js (2009) brought JavaScript to the server, and now boiled frogs write their backend and frontend in the same language: the worst one. Someone help them!

Searching for a solution

You thought you would develop your product, be done, sit back, let the profits come in and never work again. Then you learned Chacon's lesson: software is a tamagotchi. Like a virtual pet, software has its own needs that must be tended to, over time, constantly. That's normal in software. What is abnormal is the furious intensity of the tamagotchiness if you use web tech: if you don't update it, in only 4 years it is legacy code that nobody wants to maintain.

In short, you had a problem, so you decided to write a web app. Now you have 9 problems, with more to be expected in the future.

We want to make web apps, yes. But with decent tools!

Through the years I have tried many alternatives to JS, especially those that promised I could write my web apps in Python, the most legible language. But I never felt they were mature enough to actually use. They always came with serious drawbacks, such as more difficulty debugging, due to translation to JS.

Still within web tech: Mithril

The best I could do was use basic JavaScript as much as possible, avoiding frameworks that interfere in my data. Something like Mithril.js, a reactive library with limited scope, is the best you can choose. When I use Mithril, my state management library is {}. Do not let a framework dictate how your data should be organized!

You must isolate your business logic from JS frameworks. Write the core of your system with one principle: importing the JS framework is not allowed! Keep the code that uses the framework very thin. This is the only way some of your code can survive these frameworks, which usually last only 4 years.

Avoiding the situation in which your entire frontend is suddenly a pile of legacy code is so important that it trumps other considerations, such as the availability of ready-made widgets for your framework. There are only one or two widget libraries for Mithril out there. To avoid reinventing the wheel we switch to web components (custom elements) for very complex things such as editable sortable filterable data grids.

Beyond web tech: Flutter

The crumminess of web tech is a good reason to adopt something like Flutter. Since 2021, it can render on the web using Canvas. Like a game engine, it paints the screen before it hands the pixels over to some dumb surface or canvas of the platform it is currently sitting on. Therefore, my layout will never break. I will no longer care whether browsers agree on most things. I won't have to use HTML or CSS or web frameworks. The Dart language has been getting great features, such as null safety (2021). Much better than JS and very similar to TypeScript, so learning Dart is easy for most. My Sentry will certainly contain fewer weird errors from weird browsers. And no need to ever configure a bundler.

CSS? Hahahahahaah... CSS... Good one!

Flutter is an open source cross-platform application development kit created by Google. From one codebase it generates the same application for Android, iOS, web, Windows, OS X and Linux. One million applications have been created with it.

Flutter has an initial learning curve, for sure. But in the long run, that is much less effort than keeping up with crummy web tech!

What about beginning developers? What do you think is easier, to learn HTML, then CSS, then Javascript, then Typescript, then Vue, then vite (and alternatives)... or to learn Dart and then Flutter?

But one must know when to use this kind of thing on the web. Flutter is for applications, not for content websites. A Flutter app running on the web is a heavier and slower download, does not expose its content to search engines, and does not easily integrate with the accessibility features of the web platform. Keep your blog in HTML, because HTML was created for hypertext. But it wasn't created for web apps! We have been forcing web apps onto it for years, defacing it, turning it into a monster.

And the only problem is, Flutter's performance is great on every platform, except the web, and Google is not doing anything about that – not in 2024, at least. The web seems to be a second-class platform for them.

Conclusion

Although I am only getting started with Flutter, it is already easy to see how developer productivity should be higher by using it instead of HTML, CSS and TypeScript.

My interest is not necessarily to make iOS or Android apps, no. Just make my life easier. Make a bloody app that will even run on the bloody web, without requiring that I use crummy web tech.