Here is my analysis of a July 2026 interview of Yuval Noah Harari.

I will use quote signs here, but inside them might be rephrasings instead of actual quotes. I will use quotes to separate their ideas from my comments. But the purpose is to best represent their ideas in writing.

The video starts with a regrettable monologue by the interviewer. 2-minute long.

• "No longer possible to pass wisdom to the next generation"??? Of course this is false and unjustified.

  • "We are undergoing 3 revolutions:"

• "New form of intelligence": wrong, it is not intelligent, it appears to be.

  • "Calculates": wrong, LLMs are bad at math.
  • "Decides": wrong, LLMs give only an illusion of rational thought. Or maybe I should say, an LLM can decide, but only through an irrational process.
• "Scramble to power and control that intelligence": this is not a revolution we are undergoing; just politics and a tremendous gamble, a mistaken gamble, by the entire economy. And the mistake is that AI does not exist.
• "Explosion of data that lets that intelligence know us better than we do ourselves": LLMs do not know anything, they are a database plus a word predictor. Inasmuch as it has data on us, that is an egregious infringence on our privacy rights, and that is being imposed on us, rather than chosen by us. Revolution is a positive word, but this is positive only for those getting rich from information they have no right to have.

"Whoever controls the story controls the species."

What is new is tech overlords such as Musk are promising sci-fi dreams they cannot deliver, such as:

• data centers in space
• AI that makes scientific discoveries and fixes all of humanity's problems
• a bright future in which money no longer matters

...and such tall promises got hold of the media.

The reality:

• Data centers cause tremendous pollution and horrible diseases.
• LLMs are subsidized and their price must be multiplied by 15 before the American companies can make a profit.
• LLMs cannot reason, do not work without human oversight, cannot read a PDF, cannot become cheaper, are becoming exponentially more expensive for marginal gains, cannot understand geometry or space, are very bad at math, and have never fixed even the smallest of humanity's problems.
• If the sci-fi were true, a dystopia would be launched in which half the population would have no job, and money would be more important than ever, and more inequality would exist than ever, and AI would be used for oppression, not for launching a Star Trek era.

"The storyteller may not be human."

Wrong: LLMs are terrible at telling stories, it's like flipping a coin. Nobody wants to read books written by LLMs, they are full of off-kilter metaphors, jokes that make no sense and are not funny, in fact authors are being canceled based only on a belief (whether true or often false) that they used AI to write a book.

The tools that say they can detect AI-written text do not work. They will say the Bible was written by AI, and classics such as Mark Twain. Therefore, most of these canceled writers have been treated unfairly.

LLMs will influence commerce (its recommendations of products will in this sense "tell a story", or exert tremendous influence on consumers). However, this is worse for consumers. It's so much worse that Google had to make its own search engine worse, much worse, to compel us to use the LLM instead. In doing so, they are killing the very Open Web that is the source of human information and income. This is Google becoming adversarial to consumers, their income, and the source of information that feeds their LLM.

LLMs will only tell the story to the extent that humans allow it. Right now most people are deluded, but this situation seems unsustainable.

"AI can generate belief, manufacture evidence, and forge intimacy."

Finally, the first true statement. The power of AI is that so many people are clueless about what it really is, and believe the illusions:

• That AI is quickly getting better since 2023 (it isn't, this is just hearsay).
• That AI has empathy (it's just trained to say certain things; an LLM trained to be homophobic will be homophobic).
• That AI can be trusted in what it says (there can be no LLMs without hallucinations).

In short, LLMs are a shit technology – at least compared to what is expected of them and what is promised of them –, so the product are the illusions, and the bubble gotta burst.

"...a future we no longer author alone."

A magician, or a con man, has power as long as people believe them. AI by itself has no power and will author no future, since it does not invent or create anything – it only regurgitates its database. AI is just an incident in the history of this century: it shifts power but ultimately gets seen for what it is, not for the empty sci-fi promise of the singularity.

Only the ill effects will remain:

• The theft of human works
• The theft of potable water
• The theft of electrict energy
• The theft of investment in actually worthwhile things, just to
• Generate slop - irresponsible works that serve an immediate purpose but in the long run make humans less capable while getting the details wrong or inventing them altogether.
• History and proof become much, much harder to achieve if images and video can be so easily faked.

Here ends the sensationalist and untrue 2-minute summation of the current situation by the interviewer. Fortunately.

At 3:40 Yuval says he would like to understand how man became a language creature. He says all our complex systems are made of words. But the connection between words and the activity of building is forced, unjustified, and certainly not universally true. Systems are built out of organized thought and communication, not words. In humans, yes, thought and communication are intimately connected with words. But the only other intelligent creatures who have used words (that we know of) are primates who can use sign language and cats who can press buttons. Neither creature builds things or systems. Conversely, ants and termites build things and systems but do not use words (that we know of). In crows/ravens who use tools, the use of words is right now uncertain and under study. Ants organize work, bees can use tools, dolphins and whales can communicate, but the use of something similar to words (or that might be reencoded as words) is still uncertain in these cases.

My point is, thought might depend on words (maybe, possibly, who knows, admitted only for the sake of argument), but words themselves are not sufficient for thought, and this is exactly the point LLMs easily prove. LLMs only "know" words, and have "experience" of almost nothing else, but their "thought" and "reasoning" is only an illusion dependent on a billion-dollar database continually updated by humans, and the illusion breaks as soon as the LLM says something false or incoherent due to the limitations of the database.

4:00 LLMs are already better in using words than most (I would say most but not all) humans, in at least one sense: When an LLM reworks a text I have written, the text itself gets worse, every time. But the choice of words used is worth paying attention to. An LLM often will find words that are more general or more precise as the needs of the text may be. It is an excellent automatically applied thesaurus. I often find myself replacing several words I had used with the LLM's choice of words. I refuse to make my text weaker by weakening the points made in it – the LLM likes to write texts that affirm almost nothing about the world. But I welcome the better vocabulary. However, a dictionarist, or the right kind of intellectual or writer, obviously will beat an LLM in choosing the best words.

Notice how it is not true that "words are the operating system of civilization" and that "something will be better at words than we are": the thing is already great at word choice, but it is much worse in affirming what is true, or affirming something interesting or daring or even worth saying. An LLM has nothing to say. This is because the thing doesn't think and doesn't reason, so the whole of its text is worse, only atoms of it are better.

A decorator can choose wallpapers that will absolutely enliven your rooms, or help express your personality, but please don't hire the decorator to build the entire building for you – insofar as the decorator is not an engineer.

An LLM is a decorator, not an engineer.

4:42 "Perhaps AI is language itself liberating itself from apes." Again, just sci-fi. I don't see anything wrong with this idea in theory, but nothing in LLMs warrants this kind of hope. (Our current AI is a dumb technology.) Again he is talking about the singularity: AI breaks free from its dependency on human resources. Good if this happens when it is actually intelligent, bad if it wants to turn the universe into paperclips. But nobody has developed the technology that actually makes an intelligent being. For all we know right now, this sci-fi scenario might be a thousand years in the future.

I am tired of these people talking about AI as if the sci-fi future were at hand. They should shut up about it and start talking about what is really happening.

5:15 "Technological advances within language... the printing press... AI is obviously a massive leap ahead in that".

Again the interviewer is incoherent. The printing press is not an advance within language. It absolutely is external to language. It just means easier reproduction and distribution of language. AI affects neither distribution of language (the Web did) nor anything within language (LLMs do not have the discipline necessary to create systems).

Here are things that are advances within language:

• New ideas in grammar, new systems of grammar
• Conlangs such as latino sine flexione, volapuk, esperanto, toki pona etc.
  • Conlangs successfully threw away the many unnecessary parts of grammar present in natural languages
• Some programming languages (only a few)

This century is actually one of regressions in language:

• Many cannot spell, write correct or coherent sentences, use the right word etc.
• Many no longer recognize the value in being able to.
• Slang is generally stupid, badly chosen (taken from the opposite end of the spectrum as a means of exaggeration, resulting in possible confusion), and promotes a culture of crime. Examples: "dope" meaning awesome, "sick" meaning awesome, "badass" meaning good etc.
• English speakers now use adjectives in place of adverbs, as if adverbs were unnecessary.
• Prose that sells today (and is therefore recommended or even required) is widely recognized by authors as worse in many ways than the prose of the past: the book market has rules that make for worse books, not better.
• PC hysteria made people fix the wrong problems; e.g. the default git branch was always "master"; the language of master/slave used in many places in engineering was suddenly considered offensive with no real justification; and now the default git branch is called "main", in order to protect the feelings and dignity of oppressed git branches. Most of the insistence on politically correct language is a loss of time inasmuch as it does nothing to affect the actual prejudices within people's minds. After all these decades of language change, racists remain a large fraction of populations; they were not swayed by the switch from "black" to "African American", which not only made direct language illegal (if I want to refer to dark skin), but also made it geographically erroneous in many cases. The real content of the switch is a sign of respect, even if the respect comes at the cost of meaning.

Even if you disagree on several of these points, I think you probably agree that it's massively farfetched for the interviewer to say that LLMs are a massive leap as a technological advance within language. It now has very important roles as translator, applied thesaurus and new powers in processing a text, which I have already said are very useful, and I hope these activities are the ones the interviewer had in mind. My point is, LLMs have no creative role in the study or development of languages. They have a creative role in nothing.

6:00 "Earthquakes in democracies?" "Democracy is a conversation among many people deciding what to do. Conversations are based on communication tech. Democracy was present in tribes and in Athens. As societies grew larger, the conversation became impossible. Radio and newspapers became that conversation. Each time the tech changes, there's an earthquake in democracy. Example: social media"

I agree with this part. Worth adding that to be educated by an LLM is inherently inferior as an experience than to being educated by a human, and therefore LLMs have a pernicious, cheapening effect on education, and should actually be kept very far from schools.

8:40 "Many people call AI a tool, but you argue it is an agent."

Our entire team of programmers talks about LLMs as a tool, because we know what it is. AI as a self-motivated agent remains only a concept from Asimov's robot stories, or Star Wars, or HAL 9000 from "2001", or David from Spielberg's film "AI". Again I wish these folk would stop pretending AI exists and would instead talk about what is real. While they don't, they sound oligophrenic to anyone who knows what an LLM is. "AI" is a misnomer, all they made is a language generator.

It is completely irresponsible, today, to allow an LLM to make decisions without human supervision, and disasters are about to happen as a result of people doing exactly this.

Yuval's answer, commented: "If it's not an agent..." (it isn't) "...then it is not AI..." (you got that right) "...then the trillions of dollars spent developing it are a waste" (again you are right, the dream is not coming true and that is why the whole thing is a bubble).

"We will create a god and it will be a slave – this doesn't make sense". Well, we are creating only an illusion, not a god.

It is not possible that these guys use LLMs every day. If they did, they wouldn't be talking like this. No LLM has ever invented anything.

LLMs are not agents, it does not matter how much the term is thrown around by the marketing coming from the con men.

And here I should stop – having reviewed 10 minutes of this ridiculous conversation, and written my objections, and doubting that any of you will read them at all. 90% false, this interview is not worth watching, as I hopefully have already proved. Yuval is just one of the dazzled, spreading sci-fi lies instead of looking at the actual story.

Ĉi tiu blogaĵo ankoraŭ ne disponeblas esperante.

Ĉi tiu blogaĵo ankoraŭ ne disponeblas esperante.

Ĉi tiu blogaĵo ankoraŭ ne disponeblas en Esperanto.

Ĉi tiu blogaĵo ankoraŭ ne disponeblas en Esperanto.

Ĉi tiu blogaĵo ankoraŭ ne estas tradukita en Esperanto.

Ĉi tiu blogaĵo ankoraŭ ne disponeblas en Esperanto.

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

Ĉi tiu blogaĵo ankoraŭ ne estas disponebla en Esperanto.