Clean Code - Uncle Bob / Lesson 6 (Highlights)

Source published date: 2019-08-09

Source link: Clean Code - Uncle Bob / Lesson 6

Literature note: UnityCoin - Clean Code - Uncle Bob / Lesson 6 - Agile Solutions for Balancing Deadlines and Software Quality

Highlights

How do you manage a software project?

Managing software projects is inherently difficult because it forces a confrontation with the “Iron Cross” of project management, the fundamental constraint that you can never simultaneously fix quality, speed, cost, and scope. While traditional mismanagement often relies on “hope and prayer” or 80-hour workweeks to meet impossible demands, the various implementations of Agile, such as Scrum or Extreme Programming (XP), offer a data-driven alternative. Instead of dictating unachievable goals, effective management involves using frequent feedback loops and short iteration cycles to constantly adjust these “control knobs.” This iterative approach ensures that the project is steered toward the best possible outcome based on reality rather than original, often flawed, assumptions.

Variations of Agile Methodology

What kind of agile is it? Is this scrum, or scrum but, or scrum fall, or XP? So, do you do XP? XP, stream programming. - (View Highlight)

Reflection:

There are many implementations of Agile.

Reflections on Software Project Management Challenges

How do you manage a software project? - (View Highlight)

Reflection:

• Badly?
• Hope and prayer?
• With Great Difficulty
• Dictate and Motivate: dictate - if we don’t succeed, we let “them” win; and, motivate “hang in there”.

The High Cost of Project Mismanagement

The reason that we need to have a way to manage software projects is that mismanagement has some severe costs. - (View Highlight)

Reflection:

Leads to:

• Producing the wrong product
• Producing a product of inferior quality
• Being late
• Working 80 hour weeks

The Iron Cross: The Fundamental Constraint

why is it so hard to manage software projects? What is the fundamental cause of this? The answer to that has been known for a very long time, and it’s actually a very simple problem: good, fast, cheap — pick any three; you’re not going to get the fourth. This is called the iron cross of project management. - (View Highlight)

Iterative Adjustment: The Power of Feedback Loops

how to adjust the knobs: how good, how fast, how cheap, how done. A good manager will do that by adjusting the knobs with lots of feedback to drive the project to the best possible outcome. That outcome may not be what was originally targeted. - (View Highlight)

Reflection:

Lots of feedback - increase iteration cycles (2 weeks most common). Agile is to have multiple short iterations, so to be best informed by having more meaningful communication to help drive the product to what the customer wants without guessing what they want.

Finding the optimum solution - Data

Successful project outcomes are driven by empirical data rather than blind optimism, utilizing tools like velocity and burndown charts to provide a “10-second status” on real-world progress. This radical transparency acts as a diagnostic tool that “destroys hope” to surface the actual reality of a project, allowing managers to address complexity spikes and “estimate drift” as soon as they occur. By treating requirements as fluid and estimates as non-binding forecasts, teams can maintain alignment through shared visibility of the next major deliverable. Ultimately, the goal of these “information radiators” is to ensure everyone, from developers to stakeholders, understands the true health of the project, enabling the proactive management necessary to navigate the inherent chaos of software development.

Data-Driven Optimization for Successful Outcomes

to drive a project to a successful outcome, to the best possible outcome, what you need is data. - (View Highlight)

Reflection:

Finding the optimum solution

• We need to manage the project to the best possible outcome
• An outcome that maximizes all four qualities: good (quality), fast (schedule), cheap (cost), done/scope (the deliverable).
• To do this, we need: DATA!

Velocity: The Predictive Power of Weekly Data

what kind of data do we need? Wouldn’t this be great? This is a chart on the wall, and the chart shows how much got done every week. - (View Highlight)

Reflection:

Velocity chart. This enables managers to predict the volume of work that can be done within a week.

Visualizing the Path to Completion: The Burndown Chart

another piece of data that would be really useful, that’s a burn down chart. A burn down chart says there’s 400, and by 500, isn’t it about 500 points remaining until the next major deliverable - (View Highlight)

Reflection:

One would hope that volume of work would decrement by the average of team’s velocity.

Embracing Change: Why Requirements Must Remain Fluid

It’s software; remember, first we want the requirements to change. Any software team that freezes the requirements is making a terrible mistake. - (View Highlight)

Reflection:

This puts process in-front of getting what the customer/end-user requests.

Responsive Requirements: Empowering Customer Evolution

We don’t want the requirements to freeze; we want the customers to change the requirements as soon as they know that the requirements need to change. - (View Highlight)

Accurate Forecasting: Handling “Estimate Drift” and Complexity Spikes

But the other possible reason that that bar’s a little bit higher is that the developers looked at the project again They’ve been wrong, and so they rested, which is perfectly acceptable because their estimates are not promises, and therefore we want to know as soon as the developers realize that, you know, our original estimates for Ignite were a little optimistic. We want to know that as soon as possible, so everybody understands what’s happening with this project. - (View Highlight)

Reflection:

On the topic of burndown charts (story points left in sprint/release) we generally want to see the number of story points decrease; however, there may be a case where one would see a spike in story points. This may be a point in that an evaluation of an user story was lower than what the work required actually was (i.e. it was more complexed than they originally estimated).

Estimates vs. Promises: The Value of Early Course Correction

estimates are not promises, and therefore we want to know as soon as the developers realize that, you know, our original estimates for Ignite were a little optimistic. We want to know that as soon as possible, so everybody understands what’s happening with this project. - (View Highlight)

The 10-Second Status: Velocity and Burndown in Action

Put these two charts on the wall. Anybody can walk into the room where those two charts are, look at those charts for 10 seconds and say, “Huh, this team’s getting about 45 points a week done. I think they’re gonna be done in May. - (View Highlight)

Reflection:

Velocity chart and burn-down chart

Radical Transparency: Visualizing Project Health (or Risk)

don’t have those charts on the wall,you are not producing the data that the managers need to know how screwed they are. - (View Highlight)

The Purpose of Agile: Destroying Hope to Surface Reality

The purpose of Agile is to destroy hope. - (View Highlight)

Reflection:

HA!

Agile: A Diagnostic Tool, Not an Accelerator

The purpose of Agile is to destroy hope. Some people say, “You know, we’re doing Agile so we can go fast.” Agile does It does not make you go fast, and it doesn’t slow you down either; it doesn’t change a thing about how fast you go. Agile is just a way to produce data, so that you know just how messed up things are. Then you can manage. - (View Highlight)

Reflection:

Data driven management.

Early Detection: The Prerequisite for Effective Management

We want to know as soon as possible how messed up we are so that we can manage. Because there’s this thing that managers do; it’s called managing. We want to be able to manage the project to a good outcome. - (View Highlight)

Alignment Through Shared Visibility: The 4-Month Look Ahead

the burn down chart, which tells us the number of points until the next major deliverable. - (View Highlight)

Reflection:

All work has been planned to the next major deliverable. It isn’t management saying just do the work it’s the whole team on same level understanding what is going on. This is done every iteration - curate another 3 to 4 months look ahead.

Radical Visibility: The “Information Radiator”

The purpose of agile is to get these two charts on the wall. If you don’t have these two charts on the wall, you are not doing agile; you’re doing something else. Now, the charts have to be on the wall. Could they be in somebody’s spreadsheet somewhere? It’s better to have them on the wall because then everybody can see them, and everybody can know how screwed they are. - (View Highlight)

Reflection:

Velocity chart and burn-down chart

What is the first thing know about project - The Management Paradox

Project management begins with the deadline, the only truly fixed point, which necessitates a fluid approach to scope where features are prioritized and replanned rather than treated as rigid requirements. Because customers often cannot articulate what they truly need until they see what they don’t want, Agile utilizes iterative “show-and-tell” cycles to align the product with evolving expectations. This stands in contrast to the Waterfall model, where treating analysis and design as “finished” deliverables often leads to “process inflation” or “tacking” hacks into the code as reality shifts. By starting with an “Iteration Zero” to gather high-level user stories, teams treat documentation as a placeholder for ongoing conversation rather than a static contract, allowing the software’s inherent malleability to drive the project toward a successful outcome within the constraints of the fixed delivery date.

The Deadline: The Starting Point of Every Project

The date. - (View Highlight)

Reflection:

The first thing you know about any project, even before the name of it, is the date. When is the deliverable date?

The Fixed Date vs. Fluid Scope

the date is frozen. There’s no point arguing about the date; it’s a hard business date. The requirements are not the requirements. - (View Highlight)

Reflection:

If every feature is important than none of them are. Core features of each major release can be replanned or deprioritized, and can later be incorporated in the next iteration.

Iterative Alignment: The “Show-and-Tell” Strategy

why are they going to change all the time? Well, because the customers don’t really know what they want, and the more we talk about what they want, the better idea they kind of get about what they want. But they really don’t know what they want until they see something execute that is not what they want. - (View Highlight)

Reflection:

Agile is to work in iterations. Ideas get better with iterations. As a result show-and-tell the customers early and often to see if it is in alignment to what they envisioned the end product to be.

The Waterfall Model

The Malleability of Software: Why Agile Fits

The environment of software developers is an environment where dates are fixed, but requirements are not, and somehow we have to drive the project to a good outcome. - (View Highlight)

Reflection:

Software is made to be flexible and dynamic. Major changes can be made relatively quickly. Other engineering disciplines are not susceptible to such rapid changes; for this reason, waterfall methodologies are better suited.

The Foundation of Process: Winston Royce’s Three Phases

Winston Royce, and what he said—he wrote a very famous paper titled “Managing the Development of Large Software Systems,” - (View Highlight)

Reflection:

Break the project up into 3 major phases:

1. Analysis
2. Design
3. Implementation

The Myth of “Finished” Analysis and Design

Analysis and design are not boolean deliverables; they do not have two states: done and not done. They are simply open. - (View Highlight)

Reflection:

Fails in the waterfall model. Analysis and design are constantly evaluated and worked on.

The “Tacking” Trap: Technical Debt in the Making

Writing code. Meanwhile, the requirements are changing, and you’d like to kind of reanalyze them and redesign them, but you don’t really have time for that. So you tack them into the code - (View Highlight)

Iterative Development - Calculate Day

The Trap of Process Inflation: More of What Didn’t Work

Next time, we’re gonna have to do it right; we’ll do more analysis and more design. Now, I call this runaway process inflation. Right? You take the thing that didn’t work and you do a lot more of it. - (View Highlight)

Reflection:

It isn’t about doing more of the analysis or design. Requirements changed, so they “hacked” their way into implementation ignoring the original design documentations.

Iteration Zero: Establishing the Foundation

In that first sprint, that first iteration, the first two weeks, some people call this iteration zero. What we’re doing there is gathering some requirements. Not all of them, because we can’t get them all, but we’ll talk to the customer a little bit. This is when we’re writing use cases or, nowadays, we call them user stories. - (View Highlight)

The Card: A Placeholder for Conversation

a user story is usually just a word or two on a card. You don’t need much; you certainly don’t want a lot of detail yet. Detail comes later, so we just want to kind of have a reminder, a little card that reminds us of what this feature is. - (View Highlight)

The Control Knobs of project mgt

Effective project management relies on the ethical “early warning” provided by Agile’s continuous measurement, allowing teams to adjust the “control knobs” of schedule, staff, and scope before a crisis occurs. While the temptation to turn the “quality knob” is high, the paradox of speed dictates that the only way to go fast is to go well; sacrificing engineering standards merely creates technical debt that slows future progress. Similarly, Brooks’s Law warns that adding staff often backfires by draining the productivity of veteran members, leaving scope, negotiating which features are truly necessary, as the primary lever for hitting deadlines. Ultimately, because software is inherently difficult to estimate, as intuitive human actions are incredibly complex to describe as precise instructions, success depends on a rational environment where developers’ empirical data wins over stakeholder authority, ensuring the project is managed as a series of time-boxed course corrections rather than a fixed, impossible promise.

The Ethics of the “Early Warning”: Using the Control Knobs

early is a good time to tell everybody you’re going to be late. - (View Highlight)

Reflection:

The Control Knobs of project management:

• Schedule: Push the date back if the scope is truly “fixed”.
• Staff: Add resources (though this often slows things down in the short term).
• Quality (⚠️ DON’T TOUCH THIS KNOB ⚠️): A dangerous knob to turn, as lowering quality (less testing, “hacking” it in) creates technical debt that kills future velocity.
• Scope: Cut low-priority features to hit the date.

Brooks’s Law: The High Cost of Adding Staff

doubling the staff does not have the effect of doubling the throughput. What really happens is that when you add new people to the project, the old people slow down enormously. The whole schedule begins to slip because the new people suck the life out of the old people. You kind of hope that after a month or two the new people get smart enough to start getting faster, and even if that’s true, it’s risky as hell. Besides that, if you add more people to the project, it’s going to cost more money. - (View Highlight)

The Illusion of the Quality Knob: Going Faster by “Producing Crap”

the quality knob. Everyone knows you can go much faster by producing crap. - (View Highlight)

The Paradox of Speed: “Fast” is a Product of “Well”

you go fast. You go fast by going well. - (View Highlight)

The Negotiation: Scope as the Primary Lever

maybe, some of those requirements that we were planning on didn’t really need to be there by November. Maybe the customer could live without some of those requirements for a while. So let’s talk to the stakeholders about that and see if we can live without some of these requirements. - (View Highlight)

Data vs. Authority: The Rational Project Environment

Although the stakeholders have the moral authority and the pure righteousness, the developers have the data, and if you work in a rational organization, I leave it up to you; if you do, the data must win - (View Highlight)

The 30,000-Foot View: Agile as a Measurement Tool

Just tell us what you want first so that we never, ever deliver something you don’t need. That’s agile. That’s agile. At the 30,000 foot level, agile is a simple technique. You take a project, you subdivide it into time. In time boxes, you measure how much you get done. In those time boxes, you use that measurement to project the end date, and then you manage and manage and manage, because every software project is always a horror scene. - (View Highlight)

The Complexity Gap: Intuition vs. Instruction

Why can’t we estimate software? They can estimate other things; why can’t we estimate software? How long does it take you to tie your shoes? Seconds. How long would it take you to write the instructions to tie your shoes? You can’t even begin to estimate that, can you? - (View Highlight)

Reflection:

Why we can’t estimate software. Things we can do intuitively takes significant time to describe all the steps, edge cases, to a computer that will do exactly as you have described.

Short Cycles - Agile Software Development Practices - Extreme Programming

Agile is fundamentally a data-driven discipline designed to surfaced “bad news” early by breaking work into short cycles, rather than a method for guaranteeing fixed scope, dates, or costs. True success relies on the integration of business-facing Scrum practices with rigorous engineering disciplines; without technical foundations like test-driven development and refactoring, teams fall into “Flaccid Scrum,” where accumulating technical debt causes velocity to grind to a halt. In this framework, velocity serves as a thermometer to measure stable, predictable capacity rather than a performance goal to be increased, as unexplained upward trends often signal artificial pressure or point inflation. Ultimately, Agile is most effective for small, decoupled teams focusing on high-return tasks, where projects conclude not when a checklist is finished, but when stakeholders recognize that the cost of further work exceeds the remaining potential value.

The Iron Cross: The Impossible Promise

estimates promise— it can never be promises, never be promises. You cannot promise to deliver fixed scope by a fixed date with fixed quality and fixed cost. You can’t do that. That’s the Iron Cross. The best way to manage that situation is this: do it in lots of short cycles; get the bad news as early as possible. - (View Highlight)

The Agile Rings: From Business Strategy to Engineering Excellence

Agile is for: to get the bad news as early as possible. It’s not to go fast, just to get The bad news early: the disciplines of Agile are on the screen. - (View Highlight)

Reflection:

The Disciplines of Agile

A process extracted from “Extreme Programming (XP)”

Green outer ring - Scrum - Business-facing practices (does not deal with the internals):

• Whole Team
• Acceptance Tests
• Small Releases
• Planning Game

Blue floating in-between the rings - the team practices - how a team behaves:

• Continuous Integration
• Metaphor
• Sustainable Pace
• Collective Ownership

Red inner ring - The engineering practices - the programmer-specific practices:

• Test Driven Development
• Pairing
• Simple Design
• Refactoring

Scrum without the inner red ring is known as “Flaccid Scrum”: scrum that fails.

The Death Spiral of Flaccid Scrum

what are the symptoms of Flaccid Scrum? Closest scrum starts to work initially just fine. You go through a few Sprints, everything seems to be fine. The team is making good decisions, there’s good communication with the product owners and so on. Everything’s going along fine, and then you start to see the team slow down. Thus, the team gets slower and slower with time. Why does this happen? Because they’re not practicing the engineering practices. In the middle, the engineering practices are the things that keep the architecture and the design and the code clean, and without that, Scrum will slow down and grind to a halt. - (View Highlight)

The Efficiency of Chaos: Scrum as a Mess-Maker

Scrum is a really efficient way of making a mess really fast, unless you augment it with the engineering practices in the middle. - (View Highlight)

Reflection:

Scrum without engineering practices systematically sets the team for failure.

The Planning Game: Managing the Negotiable

the planning game. This is mostly what Scrum is about: the planning game. - (View Highlight)

The Scale Paradox: Agile is for Small Teams

Agile, by the way, is a method for small teams to do small things. Agile is not a technique for big teams to do big things. It is a method for small teams to do small things. - (View Highlight)

Scaling Through Decoupling: The “Team of Teams”

If you want to do big things, you have to use a lot of little small teams, and all the small teams are doing Agile. - (View Highlight)

The Scaling Myth: Rejecting “Agile in the Large”

Agile in the large. I’m not sure there is such a thing as Agile in the small. That’s how Agile was first defined, and it was the goal of Agile to solve the problem with small teams. Can you do Agile in the large? I’m not even sure I know what that means. Can you get many small Agile teams to build something big? Sure, sure, but you have to use Agile to do that at some greater level. No, I don’t think so. - (View Highlight)

Reflection:

Consultant BS to play pretend of a process and charge time coaching a solution for a problem that doesn’t exists.

Coordination vs. “Agile Scaling”: A Historical Perspective

We have known how to get small bunches of teams to work for years. You know, we built pyramids. We went to the moon. - (View Highlight)

The Scope of Agile: Small Teams, Small Things

Agile was just about small software teams doing relatively small things. - (View Highlight)

The Brand vs. The Value: The “Noun” Trap

the name of the product becomes more important than what you’re doing with it. - (View Highlight)

The “Cargo Cult” of Frameworks: Process as a Mask

the name of the product becomes more important than what you’re doing with it. - (View Highlight)

Reflection:

Prioritizing a “process” over impactful, meaningful, work.

The “Noun” Trap: Process as a Performance

“Have you done your Jira’s yet?” That, so that tells me there’s a symptom of a problem somewhere, like maybe the tool has become more important than the function. - (View Highlight)

The Power of Comparison: Why Relative Estimation Wins

relative estimates are better than absolute estimates. Programmers are better at doing relative estimation; everybody is better at doing relative estimation. - (View Highlight)

The Value Exchange: The Core of the Planning Game

This is the process. The stakeholders are drawing from this card, and they’re making a cost-benefit comparison: how much value do they get for the cost? - (View Highlight)

Cost-Effectiveness Analysis (CEA) or value engineering: Hunting for “Low-Hanging Fruit”

Good product owners go through the deck and select the highest value cards that have the lowest cost - (View Highlight)

The ROI Engine: Keeping the Deck Lean

the deck is growing. What’s coming out of the deck? High-value cards, cards that have high value for low cost, high return on investment cards; that’s what’s coming out of the deck. - (View Highlight)

The Law of Diminishing Returns in Product Backlogs

the deck starts to get low in return on investment. The more time goes by, the more the return on investment begins to drop away. - (View Highlight)

The Definition of Done: Value as the Finish Line

Projects are not over when everything’s done; projects are over when there’s nothing else worth doing, and the stakeholders acknowledge, “Yeah, there’s nothing else. - (View Highlight)

Iterations as Data Generators: The “Fail-Proof” Sprint

It’s impossible for an iteration to fail because an iteration’s job is to produce data. Even if you produce nothing, you have produced data. - (View Highlight)

The Canary in the Coal Mine: Zero-Point Iterations

An iteration that delivers no points is good data for the managers because boy, something’s gone wrong. Better deal with it. - (View Highlight)

Velocity as a Thermometer, Not a Gas Pedal

Iterations do not fail; the number of points in the iteration is not a goal. You’re just simply trying to measure how much you can get done in each iteration. - (View Highlight)

The Ideal Velocity: The “Flat Line” of Predictability

Time is slow and steady. Dead flat — we don’t want it to rise, we don’t want it to fall. - (View Highlight)

Reflection:

In Velocity chart we don’t want any surprises. No fluxuation in output - predictable.

The Illusion of “Improving” Velocity

You do not want to see a positive slope on the velocity curve unless you can explain it with something like, “Yeah, we added three people to the team.” Now that would be a reasonable explanation. - (View Highlight)

The “Pressure” Distortion: How Stress Corrupts Data

A positive trend probably means that someone is putting pressure on the team, and pressure on the team is going to shift all the numbers. - (View Highlight)

The Death Spiral: Velocity as a Tech Debt Detector

if the velocity chart is going down sprint by sprint, less and less and less gets done? There’s a mess; somebody’s making a mess. The engineering practices are not being followed: not enough tests, not enough refactoring; design and architecture are beginning to fail. You want to catch that real early. - (View Highlight)

Reflection:

Tech debt

Questions and Answers

Effective project management relies on moving away from “write-only” documentation toward high-impact communication and knowledge transfer. This is achieved by redefining seniority as a mandate for mentorship, where experts utilize constant pairing and the “one page ahead” rule to both teach and solidify their own mastery. To manage technical uncertainty, “spikes” are used as diagnostic stories to buy information and provide accurate estimates for complex tasks. Finally, the success of this system hinges on the Business Analyst, a “bilingual” professional who uses dual empathy to translate customer pain points into actionable requirements while advocating for the technical design needs of the programmers.

The Documentation Graveyard: Compliance vs. Communication

it’s really easy to write a lot of stuff in here, isn’t it? And it’s great because nobody reads it. - (View Highlight)

Seniority as a Teaching Mandate: The True Role of the “Expert”

Mentoring, so mentoring is the responsibility of the most senior people. The more senior you are, the more responsibility you have for mentoring, for teaching people who are younger than you. - (View Highlight)

The Senior as a Catalyst: Pairing as the Primary Duty

The most senior people should probably spend their time pairing with more junior people all the time. - (View Highlight)

The Virtuous Cycle: Learning Through Teaching

You who are senior learn how to teach. By the way, I’ll tell you a little secret: the best way to learn something is to teach it. All you have to do is stay one page ahead; so all you’ve got to do is one page ahead, one day ahead. - (View Highlight)

The Spike: Buying Information to Reduce Uncertainty

a spike is for: to estimate another story. So that’s another way you can do this data analysis thing. You say, “Okay, I need three points just to look at the data to try and imagine how long it’s going to take me to actually analyze it.” - (View Highlight)

Reflection:

A spike is a user story to estimate another user story; for example, estimate how long it will take to get the database working.

Business Analysts “The Bilingual Professional”: Bridging the Gap

Business analysts are one of the hardest jobs there is. To be a business analyst, you must be technically astute enough to talk to programmers, and you have to be personally astute enough to talk to the business side. There are a lot of people that are like that who can turn both directions and communicate well across that boundary. - (View Highlight)

Reflection:

The ability to be technical and sociable to communicate the jargon and situation to non-technical business people.

The Dual Empathy of the Business Analyst

You have to be able to put yourself in the position of the customer and understand what the customer needs so that you can communicate requirements to the software development team. But then you have to be able to put yourself In the programmer’s position, they need to understand what they are fighting against and how they need design. - (View Highlight)