More on this book
Community
Kindle Notes & Highlights
Read between
January 29 - February 3, 2021
A broken build is a Stop the Presses event. I want sirens going off. I want a big red light spinning in the CEO’s office. A broken build is a Big Effing Deal. I want all the programmers to stop what they are doing and rally around the build to get it passing again. The mantra of the team must be The Build Never Breaks.
The tests are a form of documentation that describe the system being tested.
And since you have left holes in the test suite, you suspect everyone else has, too. When you execute the test suite and see it pass, you laugh, smirk, or derisively wave your hand because you know that the passing of the suite doesn’t mean that the system works.
Do not fail the build based on insuffi cient coverage. If you do this, then the programmers will be forced to remove enough assertions from their tests in order to get the coverage numbers high enough. Code coverage is a complex topic that can only be understood in the context of a deep knowledge of the code and tests. Don’t let it become a management metric.
By writing the tests first, you will decouple the system in ways that you had never thought about before. The whole system will be testable; therefore, the whole system will be decoupled.
The idea here is that writing code that works and writing code that is clean are two separate dimensions of programming.
To say this differently, it is hard enough to get code working, let alone getting the code to be clean. So we first focus on getting the code working by whatever messy means occur to our meager minds. Then, once working, with tests passing, we clean up the mess we made.
Refactoring is not the kind of activity that appears on a plan. We do not reserve time for refactoring.
Simple Design is the practice of writing only the code that is required with a structure that keeps it simplest, smallest, and most expressive.
The more complex the design, the greater the cognitive load placed on the programmers. That cognitive load is Design Weight. The greater the weight of that design, the more time and effort are required for the programmers to understand and manipulate the system.
Seniors should take care to pair with juniors more often than they pair with other seniors. Juniors should request the help of seniors more often than they request the help of other juniors. Programmers with specialties should spend significant amounts of their pairing time working with programmers outside of their specialty. The goal is to spread and exchange knowledge, not concentrate it.
My experience and the experience of many others is that pairing, when done informally and at the programmers’ discretion, is quite beneficial to the whole team.
Finally, never, ever, ever, ask for permission to pair. Or test. Or refactor. Or… You are the expert. You decide.
The technical practices of Agile are the most essential ingredient of any Agile effort. Any attempt to employ Agile practices without the technical practices is doomed to fail.
is easy to become confused by the vast numbers of Agile methods out there. My advice to you is to ignore the menagerie. In the end, regardless of which method you choose, you will wind up tuning and tweaking the process to fit your own needs.
Does an Agile team need a coach? The short answer is “No.” The longer answer is “Sometimes.”
In general, Agile coaches are not trainers. They are members of the team whose role is to defend the process within the team. In the heat of development, developers may be tempted to go off process. Perhaps they inadvertently stop pairing, stop refactoring, or ignore failures in the continuous build. It is the coach’s job to see this and point it out to the team. The coach acts as the team’s conscience, always reminding the team of the promises they made to themselves and the values they agreed to hold.
In Scrum, the coach is called a Scrum Master. The invention of this term, and the sequence of events that followed it, were among the best and worst things that happened to the Agile community.
The Agile certifications that exist are a complete joke and an utter absurdity. Do not take the certifications seriously.
Agile is for small- to medium-sized teams, period. It works well for such teams. Agile was never intended for large teams.
The bottom line here is that Agile is about software. In particular, it is about small software teams. I am always frustrated when people ask me how to apply Agile to hardware, construction, or some other task. My answer has always been that I don’t know, because Agile is about software.
One coaching competency is powerful questioning, one aspect of which is “asking questions that evoke discovery, insight, commitment, or action.”
There is a growing body of coaching tools. Many of them can be found at tastycupcakes.org, retromat.org, and liberatingstructures.com.
The essence of coaching at the individual level is helping people solve problems on their own. Coaching at the team and organizational levels means helping teams achieve their goals on their own.
Strategic technical work has no place in their Agile process. There is no need for architecture or design. The order is to simply focus on the highest-priority item in the backlog and get it done as fast as possible—one highest-priority item after another.
Over the years, developers started seeing Agile coaches as another layer of management: people telling them what to do instead of helping them to get better at what they do.
An ideology is a system of ideas and ideals. A methodology is a system of methods and practices.
When looking at the Agile Manifesto and the 12 principles,2 we can clearly see the ideology behind them. The main goal of Agile is to provide business agility and customer satisfaction, and that is achieved via close collaboration, iterative development, short feedback loops, and technical excellence. Methodologies like Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal Methods, Feature-Driven Development (FDD), and other Agile methodologies are all means to the same end.
Focus on the Value, Not the Practice
Craftsmanship promotes software development as a profession. There is a difference between having a job and having a profession.
