More on this book
Community
Kindle Notes & Highlights
by
Andy Hunt
Read between
January 17 - January 25, 2021
Don’t Go into the Code Alone
Agile Is Not a Noun; Agile Is How You Do Things
A team that doesn’t continuously experiment with their process is not an agile team.
team, in our view, is a small, mostly stable entity of its own. Fifty people aren’t a team, they’re a horde.[75] Teams where members are constantly being pulled onto other assignments and no one knows each other aren’t a team either, they are merely strangers temporarily sharing a bus stop in the rain.
Teams as a whole should not tolerate broken windows—those small imperfections that no one fixes. The team must take responsibility for the quality of the product, supporting developers who understand the no broken windows philosophy we describe in Topic 3, Software Entropy, and encouraging those who haven’t yet discovered it.
you have to wait a week for the team meeting to ask your question or share your status, that’s an awful lot of friction.[78] Frictionless means it’s easy and low-ceremony to ask questions, share your progress, your problems, your insights and learnings, and to stay aware of what your teammates are doing.
The goal of course isn’t to “do Scrum,” “do agile,” “do Lean,” or what-have-you. The goal is to be in a position to deliver working software that gives the users some new capability at a moment’s notice. Not weeks, months, or years from now, but now.
Deliver When Users Need It
Manual procedures leave consistency up to chance; repeatability isn’t guaranteed, especially if aspects of the procedure are open to interpretation by different people.
Coding Ain’t Done ’Til All the Tests Run
the test environment should match the production environment closely. Any gaps are where bugs breed.
Even if you do happen to hit every line of code, that’s not the whole picture. What is important is the number of states that your program may have. States are not equivalent to lines of code.
Test State Coverage, Not Code Coverage
People just aren’t as repeatable as computers are. Nor should we expect them to be. A shell script or program will execute the same instructions, in the same order, time after time.
How will you know that we’ve all been successful a month (or a year, or whatever) after this project is done?
Even though your title might be some variation of “Software Developer” or “Software Engineer,” in truth it should be “Problem Solver.” That’s what we do, and that’s the essence of a Pragmatic Programmer.
the long run, we shape our lives, and we shape ourselves. The process never ends until we die. And the choices we make are ultimately our own responsibility. Eleanor Roosevelt
