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
Highlights
How do you manage a software project?
id946255380
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)
Initial thought or note on: (View Highlight)
There are many implementations of Agile.
id946254751
How do you manage a software project? - (View Highlight)
Initial thought or note on: (View Highlight)
- 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”.
id946254810
The reason that we need to have a way to manage software projects is that mismanagement has some severe costs. - (View Highlight)
Initial thought or note on: (View Highlight)
Leads to:
- Producing the wrong product
- Producing a product of inferior quality
- Being late
- Working 80 hour weeks
id946365983
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)
id946366308
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)
Initial thought or note on: (View Highlight)
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
id946366428
to drive a project to a successful outcome, to the best possible outcome, what you need is data. - (View Highlight)
Initial thought or note on: (View Highlight)
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!
id946366873
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)
Initial thought or note on: (View Highlight)
Velocity chart. This enables managers to predict the volume of work that can be done within a week.
id946367270
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)
Initial thought or note on: (View Highlight)
One would hope that volume of work would decrement by the average of team’s velocity.
id946475312
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)
Initial thought or note on: (View Highlight)
This puts process in-front of getting what the customer/end-user requests.
id946475652
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)
id946476213
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)
Initial thought or note on: (View Highlight)
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).
id946477200
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)
id946585562
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)
Initial thought or note on: (View Highlight)
Velocity chart and burn-down chart
id946585794
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)
id946585948
The purpose of Agile is to destroy hope. - (View Highlight)
Initial thought or note on: (View Highlight)
HA!
id946586088
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)
Initial thought or note on: (View Highlight)
Data driven management.
id946586120
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)
id946586207
the burn down chart, which tells us the number of points until the next major deliverable. - (View Highlight)
Initial thought or note on: (View Highlight)
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.
id946586306
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)
Initial thought or note on: (View Highlight)
Velocity chart and burn-down chart
What is the first thing know about project - The Management Paradox.
id946586714
The date. - (View Highlight)
Initial thought or note on: (View Highlight)
The first thing you know about any project, even before the name of it, is the date. When is the deliverable date?
id946589703
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)
Initial thought or note on: (View Highlight)
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.
id946589875
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)
Initial thought or note on: (View Highlight)
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
id946590014
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)
Initial thought or note on: (View Highlight)
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.
id946590244
Winston Royce, and what he said—he wrote a very famous paper titled “Managing the Development of Large Software Systems,” - (View Highlight)
Initial thought or note on: (View Highlight)
Break the project up into 3 major phases:
- Analysis
- Design
- Implementation
id946597187
Analysis and design are not boolean deliverables; they do not have two states: done and not done. They are simply open. - (View Highlight)
Initial thought or note on: (View Highlight)
Fails in the waterfall model. Analysis and design are constantly evaluated and worked on.
id947984544
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
id947984911
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)
Initial thought or note on: (View Highlight)
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.
id947985278
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)
id947985489
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
id947989318
early is a good time to tell everybody you’re going to be late. - (View Highlight)
Initial thought or note on: (View Highlight)
The Control Knobs of project management: - Schedule - Staff - Quality - Scope
id947989348
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)
id947989742
the quality knob. Everyone knows you can go much faster by producing crap. - (View Highlight)
id947989780
you go fast. You go fast by going well. - (View Highlight)
id948274909
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)
id948275131
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)
id948276804
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)
id948277012
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)
Initial thought or note on: (View Highlight)
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
id948277784
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)
id948277805
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)
Initial thought or note on: (View Highlight)
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.
id948279832
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)
id948279847
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)
Initial thought or note on: (View Highlight)
Scrum without engineering practices systematically sets the team for failure.
id948280033
the planning game. This is mostly what Scrum is about: the planning game. - (View Highlight)
id948280057
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)
id948280093
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)
id948280749
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)
Initial thought or note on: (View Highlight)
Consultant BS to play pretend of a process and charge time coaching a solution for a problem that doesn’t exists.
id948281192
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)
id948281207
Agile was just about small software teams doing relatively small things. - (View Highlight)
id949246472
the name of the product becomes more important than what you’re doing with it. - (View Highlight)
id949246498
the name of the product becomes more important than what you’re doing with it. - (View Highlight)
Initial thought or note on: (View Highlight)
Prioritizing a “process” over impactful, meaningful, work.
id949246827
“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)
id949247096
relative estimates are better than absolute estimates. Programmers are better at doing relative estimation; everybody is better at doing relative estimation. - (View Highlight)
id949247171
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)
id949247196
Good product owners go through the deck and select the highest value cards that have the lowest cost - (View Highlight)
id949247373
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)
id949247451
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)
id949247476
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)
id949247546
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)
id949247563
An iteration that delivers no points is good data for the managers because boy, something’s gone wrong. Better deal with it. - (View Highlight)
id949247592
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)
id949247731
Time is slow and steady. Dead flat — we don’t want it to rise, we don’t want it to fall. - (View Highlight)
Initial thought or note on: (View Highlight)
In Velocity chart we don’t want any surprises. No fluxuation in output - predictable.
id949247884
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)
id949247916
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)
id949248075
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)
Initial thought or note on: (View Highlight)
Tech debt
Questions and Answers
id949248248
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)
id949249550
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)
id949249824
The most senior people should probably spend their time pairing with more junior people all the time. - (View Highlight)
id949249831
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)
id949251201
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)
Initial thought or note on: (View Highlight)
A spike is a user story to estimate another user story; for example, estimate how long it will take to get the database working.
id949251449
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)
Initial thought or note on: (View Highlight)
The ability to be technical and sociable to communicate the jargon and situation to non-technical business people.
id949251938
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)