"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%.

…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:

1. How to hire a development team
2. Counterintuitive facts of software development
3. No estimates
4. On the use of harmful tools

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 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.

…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:

1. How to hire a development team
2. Counterintuitive facts of software development
3. No estimates
4. On the use of harmful tools

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.

…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:

1. How to hire a development team
2. Counterintuitive facts of software development
3. No estimates
4. On the use of harmful tools

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.

…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:

1. How to hire a development team
2. Counterintuitive facts of software development
3. No estimates
4. On the use of harmful tools

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.

Chopin's opinion

When a young Frédéric Chopin left Poland to try and become a professional composer, he did not go to Paris directly. First, he spent many months in Vienna. I am not a music historian; a few years ago I was surprised by a letter, written during his stay in Vienna (1830-31), in which he wrote:

Here waltzes are called 'works'! and Strauss and Lanner, who play for them to dance, are called Kappelmeisters. It is, however, not the case that everyone here thinks that way; on the contrary, almost everyone laughs at it, but that is why they print only waltzes. (...)

(Fragment of a letter written by Chopin in Vienna on January 26th, 1831 to his teacher Józef Elsner in Warsaw.)

A great recording of Chopin's waltzes

Functional music

The distinction between absolute music and functional music has always been important.

Waltzes are functional music, they are for dancing. Marches are for processions, lullabies serve to soothe or lull, and modern film scores often refuse to say anything more than a very dispensable atmosphere setting. Since the era of the radio, music is everywhere, filling the silence, but that's only a function – music can be more important than that.

In contrast, absolute music is for pure listening, without another external practical function. It is in the foreground of one's attention. Examples are fugues, sonatas, quartets, symphonies etc.

Children of the menuet

In the classical period, inside a sonata or symphony, usually the second movement was a menuet. Its function was to balance the seriousness of the dissertation in the first movement with a little dance, relaxing the mind. Inside the symphony, the menuet was replaced with the scherzo, and thus the symphony was no longer for the aristocracy, but for the burgeoisie. This was done by Beethoven and after that, the next notable symphony that contained an aristocratic dance was Prokofiev's first, when again something political is happening to the burgeoisie.

That was in absolute music. In functional music, the menuet became the waltz.

Chronology

When I read the letter fragment, I was a little shocked that Chopin would have such a poor opinion of an important dance form. Indeed, he thought the public had a "corrupt taste" and he claimed to be unable to play those waltzes.

But my historic understanding was lacking. I had to realize that, today, when we think of waltzes, we think of Johann Strauss Jr, with his Blue Danube and hundreds of pearls like that – but Strauss is the next generation, he lived later than Chopin!

The Strauss mentioned in Chopin's letter has to be Senior, not the Junior:

• Chopin lived from 1810 to 1849.
  • His first waltz, op.18, was published in 1834.
  • His 3 waltzes op.34 were published in 1838.
  • His waltz op.42 was published in 1840.
• Johann Strauss I lived 1804-1849.
• Johann Strauss II lived from 1825 to 1899.
  • His opus 1 was composed in 1844.
  • The Radetzky March op.228 was premiered in 1848.
  • The Blue Danube, op. 314, was composed in 1866.
  • The Emperor Waltz (Kaiser-Walzer) op.437 was composed in 1889.

Before Chopin, I can remember little else in the genre besides some Schubert, whose waltzes are miniatures, and nowhere near the complexity of Chopin's.

The waltzes Chopin knew were functional music, waltzes we don't hear anymore, music that didn't become immortal. And then Chopin's editors wanted him to write waltzes, because that's what was selling. Especially in Vienna. And for sure he felt frustrated with the genre of the waltz until then – he wanted to write opuses. So he did.

Chopin's waltzes

Everyone knows Chopin's waltzes are more for listening than for dancing, because of the pull and push necessary in the tempo. But Chopin's waltzes also have these characteristics that turn them into important absolute music:

• Counterpoint. Although the waltz traditionally is just a melody over a very straight and boring oom-pah-pah harmonic accompaniment, Chopin's accompaniment is so rich it becomes something else. There are secondary melodies and counterpoints in this accompaniment, the voicing and arrangement receives a lot of thought and experimentation. This is the main way in which he was able to turn a waltz into something worth listening to. Because in music, simultaneity is what makes something interesting.
• Chopin's harmonies are much more sophisticated than your popular tonic-dominant-tonic waltz. Chopin's chords are often more complex, more dissonant, and he knows how to create that nostalgia from a tonic pedal near the end.
• The forms of these waltzes are often simple but very well calculated, they never last longer than they are welcome, repetition is at the optimal point.
• The expression is wider and more profound. You get a couple very sad waltzes, such as the op.34 n.2 in A minor. Some sections within a waltz can be slower or faster.
• There are sometimes musical experiments in Chopin's waltzes.
  • In waltz n.5 (op.42), the 1st section has a melody in 2 against the accompaniment in 3.
  • In waltz n.4 (op.34 n.3), the main section has a dizzying stream of 8th notes instead of what the common man calls a melody.
  • In op. 70 n.3, the main section has a Bachian quality in the way a single melody really contains 2 melodies on 2 separate instruments. Another section has 2 melodies in a different way.

The melodies are always incredible, but melodies in waltzes are commonly pretty. What sets Chopin's waltzes apart isn't the extraordinary quality of the melodies, I don't think. It's the quality of the overall composition – he had to forget the function, in order to create immortal music.

In short, Chopin's waltzes are Chopin.

The king

When Strauss Jr. was composing his great waltzes, he already had the example of Chopin. I think it is arguable that Chopin was the real king of the waltz in his time, because he was really the first composer to push the functional genre well into the realm of immortal absolute music.

They recognize it as soon as it starts – on the first note, even, as the reaction of this crowd shows at 16 seconds.

We are talking about John William's main theme for Steven Spielberg's classic film Jaws (1975).

When the thing starts, it already has a certain personality, definite choices in the orchestration, that enable anyone to know what it is. It's like a tutti of the lowest orchestra. The contrabasses and cellos are helped, as the video immediately shows, by a contrabassoon and two bassoons. I think there is no bass clarinet, I can't hear it.

Actually, low strings doubled by bassoons... that's a very common orchestral sound. But I suppose if you know it's Williams, then on the first note you know what this is.

It is a truism that the theme has only two notes. I understand what people mean when they say that. Journalists have said that often when John Williams is interviewed, and he won't correct them, he accepts the number two. He says "yes, and".

But that's wrong. Of course the theme does not have only two notes, nor could it. It's a horror film, therefore it has all twelve notes.

As you probably know, there are normal people, and there are musicians. Normal people haven't counted the pitches. But any composer will – it's not a case of "ackchually", but a necessity for understanding the language and the material.

We have only examined the introduction so far, which is insinuating the theme. When it stops lurking and launches into the fast ostinato, at 40 seconds, two things happen. First, a piano joins the texture, probably to give it a very definite attack. But most importantly, you get the same 2 alternating notes, Mi and Fa – but also a third note in the accents: Re.

So the main idea, the main subject of the film, requires three notes, not two. And Re is the lowest – the note we would hear as the bass of any implied chord there. Re is used in the accents, you couldn't write the actual theme without this third note.

With 3 notes given so far, one could be forgiven for thinking we are probably in the key of D Minor. The composer is now quick to prove that wrong – at 48 seconds the texture becomes more complex. The 4-horn call is incredibly important, contributing only pitches that are a minor second apart from the 3 pitches of the ostinato. This means it could not sound more dissonant in relation to the ostinato, it could not be in a more foreign "key". The pitches are Mi Bemol, Sol Bemol, and Re Bemol.

One can play all the pitches mentioned so far by dropping one's closed hand on a piano, from C# to F#. This fact suggests a kind of dodecaphonic thinking. A composer realizes if you expand that with only one more neighbour note, you get the range of a tritone, and then you can apply dodecaphonic procedures to that, like transposing the whole thing up a tritone to use the rest of the 12-note scale.

But that is not what Williams does here. I would say the thinking is more along the lines of pitch sets, combined with polytonality, because we easily hear the two simultaneous musical events (the ostinato and the horn call) in two different "keys".

So here a public that has already forgotten polytonality (except that jazz never forgot it) is exposed to an advanced instance of it. Darius Milhaud, author of the best polytonal music, "Saudades do Brasil", would be proud.

The accents in the trombones... there is something weird about them, in this recording they sound like La Bemol. This surprised me because, as I started writing this, I was pretty sure it was Si Bemol. This video soon becomes too audio-distorted to remain useful, we must switch to a studio recording now. In the studio recording, the trombone accents are Si Bemol, definitely. (0:30)

This kind of difference is something that always happens with Williams. For his most famous pieces, he always created a Boston Pops version, with a more normal set of instruments, such that it can be played by any orchestra without hiring many extras. Thus the original film music always sounds a bit more "custom" than the orchestral suites made for concerts. But he doesn't stop at orchestration – there are changes in the discourse, in the order of the sections, and in tiny details such as this, the pitch of the trombone accents.

Would you like me to speculate about why he would change B flat to A flat? OK. Both are possible as part of the horn call scale. But B flat sounds much more in harmony with the ostinato. In fact, B flat dangerously undermines the atonality because it "wants" to become the root under the ostinato, which would then become a simple B Flat Major chord (Si bemol, Re, Fa). A flat does not have that problem, being an "ugly" tritone away from the Re.

Now (0:36) the pitches Fa and La Bemol also become a secondary part of the horn call. The end of the horn call has longer notes in this version, while in the Boston Pops version the notes are very short.

Speaking as a composer, the horn call is the actual main theme of this piece. This is because the ostinato is not amenable to development – it is most useful if it remains there doing its thing without change.

A simpleton like Hans Zimmer could also compose the ostinato – anyone could. But to make the rest of the texture and the rest of the piece, John Williams' taste, knowledge, creativity and development skill are necessary. Therefore, the value of the piece isn't really in the ostinato, it's in everything else!

One wonders if normal people have heard the rest. I think they have, but they can't talk about it, they don't have the vocabulary for it. So they talk about the two-note theme. It's a sort of musical bikeshedding that happens. If I were to interview Williams, I wouldn't ask him about the same tired old things, I would make a technical interview, a composer's interview.

At 1:00 a huge tutti is building up, the violins carry the melody, and guess what, the melody is based on the horn call. There is still something oscillating in the background in the interval of a minor second (piano?), but that is "drowned" by the rest. It is also two times slower as the oscillation in the ostinato.

At 1:20, on top of a chaotic atonal texture, flutes play some kind of American march fragment. Or maybe it's not a march, maybe it's a children's song. Either way, we are reminded of the general public having fun in the beaches – those that the main character, a reluctant hero, needs to save. This song is again superposed "in a different key" from the rest. The polytonal procedure is important in the language here. It makes sense because these people are unaware of the danger – the dangerous shark and the people having fun are in two different realities.

These are the most interesting things I could say about the Jaws theme. To sum up:

• It's never just 2 notes. In fact, it's 3. In fact, it's a horrible chromatic cluster. In fact, it's polytonal.
• The polytonality is a musical way of expressing two simultaneous, conflicting realities. But it is a latent conflict: we can hear the conflict, but the two individual situations cannot, each being "happy" in its own key.
• Anyone could have composed the ostinato. But only a jazz musician like Williams would have remembered to use polytonality to express the latent conflict.

The entire music of the film is genius of course. Not just the recognizable theme. Witness, for example, the "father and son" scene.

Here, I believe the piano and harp representing the child are in the scale of D Major, but really in G lydian. (The lydian scale is the brightest one available.) The most important thing in the melody is the C# resolving to B natural.

The innocent youth is incapable of understanding the depths of gravity that a responsible adult will have to go through. This scene drives home the simultaneous realities of the youth on vacation and the policeman on whose shoulders the responsibility for the dead girl weighs.

Of course he can only think about his problem, nothing else. What is more insistent than a 2-note ostinato? A single held note. John Williams will not mention the shark musically here, since there is no danger. An even worse alternative would be to invent a theme for the politician. Let's not do those. Not when one note will suffice.

Therefore, polytonality is used again. Guess what note is in the bass? C natural. Why?

• It's the lowest note cellos and contrabasses are able to emit.
• It's right between the C# and B natural I just mentioned, just a semitone apart from both, therefore it maximizes dissonance to the child's melody.

If the shark isn't just 2 notes and actually requires 3... at the same time, John Williams can convey an idea with a single bass note if he wants to. That's amazing!

One character imitating another... that reminds me of another Spielberg movie with another perfect musical score. In that one, the imitation is the very first act that humanizes the hideous deformed monster who, by the end of the movie, will have become your best friend in the entire galaxy and leave you in tears for his absence. But in Jaws, the point is the contrast between their two mindsets, and Williams put that contrast in the music.

Usually film music will seem to be from the point of view of one character. This is a rare example of two POVs, simultaneous, accomplished through bitonality.

When Spielberg first heard the shark theme on the piano, he didn't seem to like it. If memory serves, it went more or less like this: "Really? That's all?" "You have to imagine the orchestra, of course." "Yeah but that simple?" "It's a very primal movie you've made here, Steven."

Williams' accusation that the movie is "primal" is not true. Let us just say his scores have more complexity and truth than his assertions. Or rather, in trying to defend himself, he went for the wrong argument. The correct response would have been, "of course that's not all, that is only the ostinato. On top of that we'll have modernist techniques, an entire orchestra playing in polytonal layers." Because that is what he actually did. The music for Jaws is not based on two notes, that's nonsense.

"Jaws" was a great success, and remains one of the greatest accomplishments in cinema, not because it was primal, but because it is sophisticated. Since all the sequels lack sophistication, they are failures. This sophistication is obviously in the music, but also in the director's technique. Watch this analysis of a single scene to understand how.

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.

I'd like to show you a written impression. Here is how the Brazilian elite of São Paulo, that oh so petite burgeoisie, would sum up the first chapter of the book "Pinocchio" by Carlo Collodi:

"Once upon a time dere was... a CEO? A coach? No, justy a loggy of woody. Itchy gotchy foundgy by a puur carpinter. Dgis carpinter hadgy no shoes. He hadgy never wentchy to Miami Orlando. Dgis vacation we wentchy to Miami, we buyedy dis Niky Air. And she buyedy a New Balance and lots of maquiage in Macy's. You can buy a New Balance on de internetty butty de American one is diferaintchy, muchy better. We also bringy de iPhoney for her and de MackyBoocky Air for me oh, and a Reebocky for Allison, and one Androidy tablety for each one. De screens are so brighty our eyes hurty. We watchy Nettiflix and play Farmy and Sugar Crushy. We wenty to Disney and Sea Wordy in Orlando. No, we don'ty liky Epickotty Center. We liky shoppin center. In de Fri Shopi we buyi wiscky andy vodka andy a new Playstation for Allison. You wantchy caipirinha? Is exclusive!"

This is a weird post. It tries to connect certain ideas through history, culture and politics. Not sure it manages to convince, but also not aware of the weak points.

The Belle Époque

To deeply understand Esperanto, start from the Belle Époque. It was "a period characterised by optimism, enlightenment, regional peace, economic prosperity, colonial expansion, and technological, scientific, and cultural innovations. In this era (...) the arts markedly flourished, and numerous masterpieces of literature, music, theatre and visual art gained extensive recognition".

The conquest of Africa by European nations certainly makes the époque much less belle. But we are not here to say anything is perfect; we are here to compare this period with the absolute disaster that followed: the two world wars.

In classical music (the thing I know and love), the peaceful period is definitely THE time of complex masterpieces and expansion of language. Think Debussy, Stravinsky, Mahler, Richard Strauss, Ravel, Rachmaninoff... In my opinion this was the ultimate climax of the art of music.

In technology, that is the time of the invention of the automobile, the metro, the telegraph, steel, the railroad... all products of the Second Industrial Revolution. Esperanto was created early in the Belle Époque, giving it a chance to help feed the optimism.

What Esperanto is

Esperanto is simultaneously:

• not only a designed language;
• but also a masterpiece of literature, in its design choices that aren't absolutely perfect but still work so well that no improvement proposal, however reasonable, was enough to sway the community;
• achieved through a scientific breakthrough: the understanding of what parts of grammar are useful (kept) and which are simply inconsequential rules (dropped);
• amounting to...
  • a new technology: a language so easy that it can be learned in only 200 hours of study;
  • an economic breakthrough: achieving easy, precise communication after much less investment (of hours of language study and therefore money);
  • and a cultural innovation: the idea of a language that actually deserves to be everyone's second language.

Esperanto is the only technology from Star Trek already available today (Federation Standard). Learning languages is not a skill or propensity that every human has – it is only one of many intelligences. Tomorrow every child will need to spend 2500 hours learning Mandarin. If the world were coordinated, they could instead spend only 200 hours learning Esperanto.

What Esperanto means

There is no great achievement without optimism. Like Star Trek and the Belle Époque, Esperanto expresses optimism:

• optimism about the power of reason
• optimism that truth can come to light (be expressed)
• optimism that human relations will improve
• optimism that peace will be attained and be the default
• optimism that racism shall become a thing of the past, a forgotten problem
• optimism that humanism will have priority over nationalism

The enemy: nationalism

Weird nationalist content in the Esperanto course of Duolingo

This last item is unfortunately the least well understood. Nationalism continues to be an enormous force in the world and people have not generally recognized it as the enemy it is – a menace to each item in the above list. I have seen more than a few nationalists among Esperantists. In fact, they think of Esperantujo itself as a sort of nation...

What could be more strange, more presumptuous, than saying "Nice to meet you, samideano!" (The word means "fellow with the same ideas".)

Do you see nothing strange in a Youth Congress that has everyone sing a little Esperanto hymn at the beginning? Must we confirm the general suspicion that Esperanto is a cult?

Nationalism is the illusion that some brothers are family and others aren't. Nationalism is manipulation enough to make you join a war that is not in your interest, it is only in the interest of the powerful. Nationalism is to feel more pride and connection in your immediate family than in the accomplishments of distant people, which ultimately is not a wise discrimination, even if considered natural.

I will give you an example. These days I am seeing a stupid idea repeated more and more: That white people never had a single creative moment, that they can only steal the creativity of other nations, present those as their own, profit from them and enslave other groups. Whites are just parasites. This idea loses perspective of all cultural complexity and explains everything based on the absolutely stupid criterium of skin color. It is ethno-nationalist, and therefore, wrong.

Racism is a nationalism

One day I thought to myself, "today I will leave Schumann alone and get way out of my comfort zone. I will learn a bit about the history of hip hop, which I never listen to". So I found a video on that theme.

But suddenly I caught the black historian of rap stating that white people have an inner void of sadness which can only be filled with the happiness of black music. According to him, this is why white people love black music and keep stealing it. This is of course exemplified with well-known facts of the industry of rock and pop music in the 20th century. For instance, Elvis Presley grew among black musicians and delivered black music to a racist establishment that wouldn't allow black musicians to rise.

As a white man who always loved classical music, the fact that the preacher would see me as inferior, uncreative and immoral a priori, based on the color of my skin... is quite offensive, of course. So when I heard that, first I had a stupid reaction of spite: I thought "keep your hip hop, dude; I will keep my Grieg".

But that is a dumb thought. It falls into these traps:

1. Accepting the racial categories – in fact, accepting them as the most important parameter.
2. Feeding into the racial war proposed by the mistaken historian brother.
3. Throwing away the baby (hip hop) with the dirty bath water (the ridiculous theory).

But culture is much more complex, isn't it. There are many cultures simultaneously at play, and honestly blackness isn't a legitimate musical parameter, it is quite imaginary. (This point will become clear gradually.)

The intelligent thought is to remember that culture feeds on itself and builds on top of itself, and should be free to do so; that culture is for all people; that Bach is for everyone as much as hip hop is for everyone; so the bro's way of thinking is contrary to the way culture really works, contrary to inclusivity, and just straight racist, inasmuch as it pre-judges a set of people, discriminating by their skin color.

The correct thought is exemplified by Heitor Villa-Lobos, a great Brazilian composer, born in 1887, the same year Esperanto was first published. Villa-Lobos composed a famous series of works titled "Bachianas Brasileiras", in which we find traits of Bach's music miscigenated with things typical of Brazilian folkloric music. In so doing, he is implicitly showing, that the smart thing to do, is yes to import that which is good, and Bach is sooo good, so universally considered the best composer that ever lived, that there's no doubt that Bach should converted into a Brazilian thing. The immortal German should become one of the components of the mestiço country, for sure.

The smart thing to do in culture is import good things and ignore bad things. That is what classical music has always done – building on top of itself and folkloric musics. To be clear, cultural "appropriation" is the wrong diagnostic. The problem was systemic racism that prevented the originals from being as successful and rich as they deserved to be. The problem is racism, not appropriation. Appropriation is the correct, normal, endemic modus operandi of culture.

In other words, Elvis Presley was never wrong to sing in the genre that he loved. It would have been absurd to shout him down: "hey Elvis, stop that, that belongs to others!" Based on skin color!!! You think the music didn't belong to Elvis because of the color of his skin??? Preposterous!!! Can you imagine such a thing??? The racism was wrong – Elvis was right, he wasn't racist! The racism prevented black musicians from having all the success they deserved. Elvis had nothing to do with that! Elvis is guilty of no sin, let the man sing!!!

The thought of the historian is completely ignorant of how culture works. We are all exposed to it. Although I would prefer Ravel, I hear bits of hip hop constantly, because I live in the world. Conversely, he is deluded if he thinks he was never influenced by Tchaikovsky. Everyone has heard Tchaikovsky whether they wanted to or not. We are all exposed to the culture, it influences us, there is no escape.

He talks as if the software used to create hip hop weren't full of the work of European engineers...

His thought tends towards mirroring the identitarian movement. That's nothing to be proud of. This is what happens when minds get contaminated with nationalisms, any kind of them.

Recognize this moment is anti-enlightenment

Notice how much humanity accomplished during the Belle Époque; realize how many great dreams arose in that period; calculate what a waste and what shattering of those dreams the 2 World Wars represented – wars that wouldn't be possible in the absence of the formidable power of nationalism. Think of how much further along civilization might be if the wars somehow hadn't occurred...

And then think about the present moment. Think about the polarization, the extremism found in all political sides... When was a Zamenhof more needed?

I'll tell you what I think:

We must seek to be centered, subtle and rational in our expressed views.

Ideologies are good while subtle, well written and well read. Ideologies become bad in the messy behavior of the masses, which ends up directly contradicting the books that propelled them. So reject theories that:

• cynically negate rationality;
• cynically affirm the relativism and subjectivity of truth(s), declaring objective truth unreachable in principle;
• cynically affirm that human "races" are forever in opposition;
• manipulate people, striving to consolidate a new nation through the old technique of pointing to a supposed common enemy guilty of all problems, while defending the value of inclusivity.