Nando Florestan's blog (Posts about agile)

The new employee

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

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

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

"What about him?", asked Long.

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

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

"We?"

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

"Okay, I'm listening."

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

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

"Mid?"

"Just meh code."

"Okay. You mean ravioli?"

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

Pascal took a breath and continued:

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

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

"Hackerman went to the Microsoft Academy."

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

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

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

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

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

"How come?"

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

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

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

"Really?"

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

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

Pascal sighed.

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

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

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

Pascal was gesticulating:

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

Pascal gasped:

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

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

"Of course. You know what he does?"

"What?"

Pascal got up and started walking back and forth.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pascal touched his forehead with all his fingertips.

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

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

Johnson seemed a little shocked that Pascal was almost yelling.

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

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

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

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

Pascal resumed walking.

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

Johnson crossed his arms. Pascal caught his breath.

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

Johnson was getting impatient. Pascal doubled down.

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

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

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

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

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

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

Johnson sighed – Pascal was preaching again.

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

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

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

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

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

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

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

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

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

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

Pascal started biting his tongue.

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

Pascal blinked a few times.

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

"Yep!"

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

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

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

"Well, such is the world, Pascal."

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

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

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

On the use of harmful tools

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

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

This series contains these posts:

Summary

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

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

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

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

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

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

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

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

So my thesis is:

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

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

After I wrote this post, I found:

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

A word about intelligence

What is intelligence?

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

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

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

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

The argument

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

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

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

The same reasons apply to your employees:

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

Now in more detail

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

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

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

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

Am I talking about writers or coders? Yes.

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

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

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

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

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

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

Example 1

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

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

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

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

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

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

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

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

Planning the obsolescence of writing itself

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

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

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

Nadella might discover he is a replicant himself...

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

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

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

This is not prejudice

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

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

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

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

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

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

Of course not. Not in a million years.

Be a man. Get awesome.

Example 2 (mild)

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

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

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

Example 3 (the kicker)

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

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

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

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

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

Exercise for the reader

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

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

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

The hysteria about AI

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

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

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

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

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

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

The truth is, code written by AI is:

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

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

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

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

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

Code review is a scam

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

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

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

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

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

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

import caprese

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

…just like UML was a scam

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

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

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

The alternative to code reviews

(Pair programming is the right answer.)

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

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

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

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

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

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

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

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

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

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

AI does not edit

But it's even worse than that.

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

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

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

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

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

Managers never explain the reason

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

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

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

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

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

No estimates!

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

This series contains these posts:

Estimation is impossible

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

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

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

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

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

History

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

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

Rubbish

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

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

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

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

Software creation is an interaction

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

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

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

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

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

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

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

Managers do not understand the word "estimate"

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

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

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

"That's bullshit!!!"

"You got that right!!!"

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

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

What to do

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

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

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

Not convinced?

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

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

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

Counterintuitive facts of software development

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

This series contains these posts:

The book

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

On Waterfall

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

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

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

Brooks' Law

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

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

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

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

First reason for Brooks' Law

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

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

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

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

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

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

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

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

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

Second reason for Brooks' Law

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

This is one of the funniest. Brooks explains:

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

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

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

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

On business analysis

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

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

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

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

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

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

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

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

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

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

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

I found the same thought expressed in another quote:

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

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

It's not requirements

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

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

Bugs are priority zero

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

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

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

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

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

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

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

More than 40 hours a week hurts the project

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

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

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

Do not pressure developers to work faster

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

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

So the software is now more buggy and less maintainable.

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

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

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

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

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

Robert C. Martin expresses this concept best:

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

Pressure your developers and suffer the consequences.

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

Technical debt

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

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

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

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

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

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

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

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

Truck number

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

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

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

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

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

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

Pair programming

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

That is one reason to program in pairs.

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

There are more reasons, too.

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

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

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

Don't tell me how long it will take

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

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

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

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

Conclusion

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

How to hire a development team

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

This series contains these posts:

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

The question

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

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

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

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

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

Waterfall

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

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

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

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

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

Problems

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

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

Historically, the Waterfall method had these serious problems:

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

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

Fixing waterfall

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

Let's just try to begin to understand Agile.

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

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

Here are some obvious things:

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

Therefore, when working with an Agile team:

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

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

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

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

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

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

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

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

Conclusion

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

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

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

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

You're too quick to dismiss Agile

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

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

However, there's widespread confusion:

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

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

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

The manifesto

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

https://agilemanifesto.org/

It simply means that:

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

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

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

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

Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Extreme Programming (XP)

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

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

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

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

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

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

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

Software is a tamagotchi

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

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

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

Reality is like Chacon said:

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

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

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

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

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

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

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

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

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

Technical debt

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

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

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

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

Clean code

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

Here's a bit I would like to emphasize:

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

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

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

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

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

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

Oh, and here is his description of technical debt.

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

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

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

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

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

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

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

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

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

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

Conclusion

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

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

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