All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
8667 bites
Page 428
Simple Design: The Simplest Thing That Could Possibly Work
Simple Design means building only what's needed now, not what you might need later. In agile projects like Extreme Programming, this keeps code lean for changing requirements.
Trunk-Based Development: One Mainline to Rule Them All
Trunk-Based Development means all developers commit to a single shared branch, main or trunk. This is common in CI/CD environments for frequent updates.
SOLID Principles: Writing Maintainable Object-Oriented Code
SOLID principles are five design rules for writing maintainable object-oriented code. They guide you toward creating flexible systems that are easy to change. The footgun is treating them as rigid laws, leading to over-engineered and complex solutions.
Refactoring: Cleaning Code Without Breaking It
Refactoring is like renovating a house's internals without changing its outward appearance. It improves code design and readability without altering external behavior, making it easier to maintain or extend.
Test-Driven Development: The Red, Green, Refactor Cycle
Test-Driven Development (TDD) flips the script: you write a failing test *before* the feature code. This 'Red, Green, Refactor' cycle ensures every piece of code is testable. It's common in agile for building robust features.
Actionable Agile Metrics: Predicting 'Done'
Stop guessing 'done' and start forecasting with data. Actionable Agile Metrics use historical flow data—like cycle time and throughput—to answer 'When will it be done?' for customers who need predictability.
Double-Loop Learning: Question the 'Why', Not Just the 'How'
Double-loop learning means questioning the 'why' behind your work, not just fixing the 'how'. Instead of only correcting errors, you challenge the underlying goals. This is crucial in retrospectives when a team realizes their entire approach was flawed.
The 4Ls Retrospective: Loved, Loathed, Longed For, Learned
The 4Ls retrospective is a structured way to capture a team's feelings after a project. It asks what they Loved, Loathed, Longed for, and Learned to create an action plan. A common pitfall is only focusing on negatives, missing key insights from the other Ls.
Radical Candor: Care Personally, Challenge Directly
Radical Candor is a feedback framework that combines caring personally with challenging directly. It's used to give clear, kind guidance—both praise and criticism—that helps people grow.
SMART Goals: From Vague Hopes to Actionable Plans
SMART criteria turn vague hopes into concrete plans by forcing goals to be Specific, Measurable, Achievable, Relevant, and Time-bound. It's used in project planning and performance reviews.
Fishbone Diagram: Mapping Problems to Root Causes
A fishbone diagram maps a problem to its potential root causes. It's a structured brainstorming tool used in retrospectives or post-mortems to explore *why* something happened.
Cumulative Flow Diagrams: Spotting Workflow Bottlenecks
A Cumulative Flow Diagram is a geological cross-section of your project, showing work moving through states over time. Agile teams use it to spot bottlenecks by seeing where tasks pile up. The footgun is misinterpreting a widening band as a failure.
Start, Stop, Continue: A Simple Action-Oriented Retrospective
This retrospective turns feedback into action by asking what to start, stop, and continue doing. Teams use it after a sprint to improve processes and collaboration. The footgun: the 'Continue' list can become a long praise session, losing focus on improvement.
Retrospective Prime Directive: Assume Positive Intent
Assume everyone acted with the best intentions given their context. The Retrospective Prime Directive creates psychological safety for a blameless discussion, focusing on systemic issues, not individual fault.
PDCA Cycle: The Scientific Method for Business Improvement
The PDCA cycle is the scientific method for business: Plan a change, Do the experiment, Check the results, and Act on the findings. It's used to refine manufacturing or improve software cycles.
Continuous Delivery vs. Deployment: The Final Step
Continuous Delivery automates releases to a staging environment for a manual go-live decision, while Continuous Deployment automatically pushes every passing build to production. Use Delivery for business-timed releases; use Deployment for maximum velocity.
Emergent Architecture: Build Just Enough, Just in Time
Emergent architecture lets design evolve as you build, prioritizing adaptation over upfront planning. It's used in agile teams where requirements are unclear.
Feature Toggles: Decouple Deployment from Release
A feature toggle is a runtime switch that lets you ship dormant code and activate it later, decoupling deployment from release. It enables canary rollouts and A/B tests.
Continuous Integration: Catching Bugs Early
Continuous Integration (CI) treats code merging like a continuous stream, not a big-bang event, to keep the main codebase stable. On every commit, an automated system builds and tests the software to catch issues immediately.
Timeboxing: Fix the Time, Flex the Scope
Timeboxing fixes the duration for a task, not the scope. You work for a set period and then stop, forcing focus and preventing endless work. It's the core of Agile sprints and daily stand-ups. The footgun is treating it as a hard deadline to cram.