Tip 84. Maintain Small, Stable Teams
Teams should have 10-12 people
No broken windows:
Teams as a whole should not tolerate broken windows.
The team must take responsibility for the quality of the product, supporting developers who understand the no broken windows philosophy (p. 438)
[Q]uality can come only from the individual contributions of all team members. Quality is built in, not bolted on. (p. 438)
Boiled frogs:
Encourage everyone to actively monitor the environment for changes.
Stay awake and aware for increased scope, decreased time scales, additional features, new environments—anything that wasn’t in the original understanding. (p. 439)
Tip 85. Schedule it to make it happen
Schedule your knowledge portfolio:
- Old systems maintenance: don’t shove this work in the corner
- Process reflection and refinement: find out what works and what doesn’t; then, fit it.
- New tech experiments: deliberately spend time prototyping new things as analyzing results
- Learning and skill improvements: make time to spread the knowledge
Communicate team presence:
The team as an entity should communicate clearly with the rest of the world.
Great project teams have a distinct personality. People look forward to meetings with them, because they know that they’ll see a well-prepared performance that makes everyone feel good. The documentation they produce is crisp, accurate, and consistent. The team speaks with one voice. They may even have a sense of humor. (p. 441)
Don’t repeat yourselves:
Good communication is key to prevent duplications.
Tip 86. Organize fully functional teams
Team tracer bullets:
The teams needs all sort of people from different backgrounds to incrementally and iteratively create small bits of end-to-end functionality
Topic 50. Coconuts don’t count: context matters
Tip 87. Do what works, not what’s fashionable
Pilot the idea with a small team or set of teams. Keep the good bits that seem to work well, and discard anything else as waste or overhead.
Tip 88. Deliver when users need it
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. For many teams and organizations, continuous delivery feels like a lofty, unattainable goal, especially if you’re saddled with a process that restricts delivery to months, or even weeks. But as with any goal, the key is to keep aiming in the right direction. (p. 449)
Note that being able to deliver on demand does not mean you are forced to deliver every minute of every day. You deliver when the users need it, when it makes business sense to do so. (p. 450)
Topic 51. Pragmatic Starter Kit
Whether it is the build and release procedure, testing, project paperwork, or any other recurring task on the project, it has to be automatic and repeatable on any capable machine. (p. 452)
In order to ensure consistency and repeatability, we need to be able to automate procedures.
Pragmatic Starter Kit:
- Version control
- Regression testing
- Full automation
Tip 89. Use version control to drive builds, tests and releases
Build, test, and deployment are triggered via commits or pushes to version control, and built in a container in the cloud.
Release to staging or production is specified by using a tag in your version control system.
Tip 90. Test early, test often, test automatically
Write a lot of unit tests.
Tip 91. Coding ain’t done til’ all the test run
The automatic build should run all available tests: unit testing, integration testing, validation & verification, preformance testing, etc.
Different stages of testing:
- Unit testing: Testing the module if it works in an independent setting → If the parts don’t work by themselves, they probably won’t work well together. All of the modules you are using must pass their own unit tests before you can proceed.
- Integration testing: Testing the major subsystems that make up the project work and play well with each other → check for good contracts
- Validation & Verification: compare the end-user data and test data and validate that the system meets the functional requirements of the system
- Performance testing: Testing if the software meets the performance requirements under real-world conditions → with the expected number of users, or connections, or transactions per second, is it scalable?
Tip 92. Use saboteurs to test your testing
After you have written a test to detect a particular bug, cause the bug deliberately and make sure the test complains. This ensures that the test will catch the bug if it happens for real. (p. 457)
Tip 93. Test state coverage, not code coverage
Even if you do happen to hit every line of code, it doesn’t ensure it will work in all kinds of states
Use property-based testing techniques to generate test data according to the contracts and invariants of the code under test.
Tip 94. Find bugs once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. The automated tests should be modified to check for that particular bug from then on, every time, with no exceptions, no matter how trivial, and no matter how much the developer complains and says, “Oh, that will never happen again.” (p. 459)
Tip 95. Don’t use manual procedures
Introducing manual steps will break the development process
Topic 52. Delight your users
Tip 96. Delight users, don’t just deliver code
Your users are not particularly motivated by code. Instead, they have a business problem that needs solving within the context of their objectives and budget. Their belief is that by working with your team they’ll be able to do this. (p. 462)
Think about the end goal of the software → this is what the user expects
- Make sure everyone on the team is totally clear about these expectations.
- When making decisions, think about which path forward moves closer to those expectations.
- Critically analyze the user requirements in light of the expectations.
- Continue to think about these expectations as you progress through the project
Topic 53. Pride and prejudice
Pragmatic Programmers don’t shirk from responsibility. Instead, we rejoice in accepting challenges and in making our expertise well known. If we are responsible for a design, or a piece of code, we do a job we can be proud of. (p. 465)
Tip 97. Sign your work
Have code ownership, while respecting others
Tip 98. First, do no harm
Tip 99. Don’t Enable Scumbags
Tip 100. It’s your life. Share it. Celebrate it. Build it. And have fun!
