Back to Public Maps
Seven Pillars
by André Dhondt 03/30/2018
Seven Pillars
by André Dhondt
1. customer satisfaction
1.1. split testing
2. Bugs
3. Relational vs Hierarchical Thinking
4. Performance / Response Time
5. Non-functional requirements
5.1. Load / Capacity
5.2. Robustness / Long Duration
6. Critiquing the Product
6.1. Test Harness for Legacy Code
6.1.1. test seams
6.1.2. dependency breaking
6.1.3. sprouts and strangling
7. easy to use/learn
7.1. simple
7.2. functional completeness
7.3. overall coherence
7.3.1. Evolutionary Design
8. Domain-Driven Design
9. Persistent
10. JDUF-just enough design up front
11. Code Smells
11.1. Don't Repeat Yourself
11.2. Law of Demeter (Tell Don't Ask)
11.3. Metrics
11.3.1. Test Coverage
11.3.2. Lines of Code (sphags)
11.3.3. Static Code Analysis Tools
11.3.3.1. Find Bugs Report
11.3.3.2. Cyclomatic Complexity
12. Collaboration
12.1. Sufficient communication
12.2. Frequent
13. Business Value
13.1. validating
13.1.1. Release Management
13.1.1.1. Flow
13.1.1.2. Stories
13.1.1.2.1. Story Estimation
13.1.1.2.2. Story Splitting
13.1.1.2.3. Story Writing
13.1.1.3. Delivering In Small Slices
13.1.1.3.1. Incremental
13.1.1.3.2. Iterative
13.1.1.4. Product Backlog
13.1.1.4.1. Sprint Backlog
13.1.1.5. frequent delivery
13.1.1.6. Basic Throughput Accounting
13.1.1.6.1. Cadence
13.1.1.6.2. Limiting Work in Progress
13.1.1.6.3. Optimize the whole
13.1.1.6.4. Value Stream Mapping
13.1.1.7. Kanban
13.1.2. Time management
13.1.2.1. Pomodoro
13.1.2.2. Getting Things Done
13.1.2.3. Timeboxes
13.2. avoiding waste (muda)
13.2.1. Extra features
13.2.2. Heavy specs
13.2.3. Handoffs
13.2.4. Waiting
13.2.5. Multi-step analyze-dev-test-verify...
13.2.6. Re-creating knowledge
14. Supportive Culture
14.1. Conflict management
14.1.1. diagnosis
14.1.1.1. dissapointment
14.1.1.2. friction
14.1.1.3. disconnect
14.1.1.4. disagreement
14.1.2. productive discussion
14.1.2.1. Consent-based decision making
14.1.2.2. Knowledge vs Information
14.1.2.3. Facilitation
14.2. respect
14.2.1. Craftsmanship Manifesto
14.2.2. Declaration of Interdependence
14.2.3. Agile Manifesto
14.2.4. growing trust
14.2.5. individuals and interactions over processes and tools
14.2.6. give teams what they need & trust them to get the job done
14.3. commitment
14.3.1. Nudging for Improvement
14.3.1.1. Jiggling (Change Agent)
14.3.2. Patrick Lencioni’s Five Dysfunctions of a team
14.3.2.1. Absence of Trust
14.3.2.2. Fear of Conflict
14.3.2.3. Lack of Commitment
14.3.2.4. Avoidance of Accountability
14.3.2.5. Inattention to Results
14.3.3. help
14.3.3.1. Knowing when you're blocked
14.3.3.2. Ask first, conclude later
14.3.3.3. Active Listening
14.3.3.4. Mentoring
14.3.3.5. Helping
14.3.4. whole team attitude
14.3.4.1. Cross-functional teams
14.3.4.2. generalizing specialists
14.3.4.3. product focus
14.3.4.4. responsibility
14.3.4.5. autonomy
14.3.5. permanent team attitude
14.3.5.1. improves productivity
14.3.5.2. enhances commitment
14.3.5.3. shared history
14.4. Space to learn
14.4.1. slack
14.4.2. accepting failure
14.4.3. sustainable pace
14.4.4. risk taking
15. Technical Excellence
15.1. Simple Design
15.1.1. KISS - Keep it simple, stupid!
15.1.1.1. Architecture--simplest thing that could possibly work
15.1.1.2. One level of abstraction
15.1.2. Design Patterns
15.1.2.1. Evolutionary Iterative Development
15.1.2.2. Emergent Design
15.1.2.2.1. Refactoring to Framework
15.1.2.2.2. Avoid Speculative Generality
15.1.2.3. MVP / MVC Patterns
15.1.2.4. Separation of Concerns
15.1.2.5. FCoI - Favour Composition over Inheritance
15.1.2.6. Modeling
15.1.2.6.1. CRC (class responsibility collaborator) cards
15.1.2.6.2. UML diagrams
15.1.2.6.3. whiteboard discussions
15.1.3. Craftsmanship
15.1.3.1. Coding by Intention
15.1.3.2. Clean Code
15.1.3.3. Boy Scout Rule
15.1.3.4. Source Code Conventions
15.2. Refactoring
15.2.1. SOLID
15.2.1.1. Single Responsibility Principle
15.2.1.2. Open Closed Principle
15.2.1.3. Liskov Substitution Principle
15.2.1.4. Interface Segregation Principle
15.2.1.5. Dependency Inversion Principle
15.2.2. Common Refactorings
15.2.2.1. Compose Method
15.2.2.2. Extract Method
15.2.2.3. Inline Method
15.2.2.4. Rename
15.2.3. Database Refactoring
15.2.3.1. testing databases
15.2.3.2. abstracting away from dbms
15.2.4. Test Refactoring
15.2.5. Modular Design
15.3. Testing
15.3.1. developer tests
15.3.1.1. Unit Testing
15.3.1.1.1. xUnit
15.3.1.2. Design-for-Testability
15.3.2. test-first
15.3.2.1. Test-Driven Development
15.3.2.1.1. TDD Cycle - Red, Green, Refactor
15.3.2.1.2. Which test next?
15.3.2.1.3. TDD with GUIs
15.3.2.2. Tests Used for Design
15.3.2.3. Behavior-Driven Development
15.3.2.3.1. StoryTest-Driven Development
15.3.3. customer tests
15.3.3.1. Acceptance Testing
15.3.3.2. Exploratory Testing
15.3.3.3. Testing Quadrants
15.3.3.3.1. Supporting Programming
15.3.3.3.2. Robustness / Fault Tolerance
15.3.3.3.3. Technology Facing
15.3.3.3.4. Business Facing
15.3.4. Test Automation
15.3.4.1. Test Automation Patterns
15.3.4.1.1. Test Doubles
15.3.4.1.2. 3A Pattern: Arrange, Act, Assert
16. Self Improvement
16.1. intentional practice
16.1.1. book discussions
16.1.2. online communities
16.1.3. Reading
16.1.4. Code Kata
16.1.5. local user groups
16.1.6. open source projects
16.1.7. conferences
16.2. retroflection
16.2.1. Daily self reflection
16.2.2. Self Management
16.2.3. Common Pitfalls
16.2.4. Self Awareness
16.3. balance
16.3.1. Keeping Motivated
16.3.1.1. autonomy
16.3.1.2. mastery
16.3.1.3. purpose
16.3.2. work/ health/ friends
16.3.3. social captial (networking)
16.3.4. slack
17. Product
17.1. vision
17.1.1. clear problem domain
17.1.1.1. Visualization and Presentation Techniques
17.1.1.2. Wireframe/Paper Prototyping
17.1.1.3. working directly with whole team
17.1.2. explicit goals
17.1.2.1. managed scope
17.1.3. measured progress
17.1.3.1. success metrics
17.1.3.2. split testing
17.2. solves real/valuable problems
18. Confidence
18.1. Definition of Done
18.1.1. working software
18.1.2. validated learning
18.1.3. High Quality
18.1.3.1. Zero Bugs
18.2. Visibility
18.2.1. Storyboard
18.2.2. Informative Build
18.2.3. Burn-up/down charts
18.2.4. transparency
18.2.4.1. open decision making
18.2.4.2. continuous improvement
18.2.4.2.1. Plan Do Check Act
18.2.5. Reliable Cadence
18.2.6. Using Version Control
18.2.6.1. Distributed
18.2.6.2. Optimistic vs Pessimistic Locking
18.2.6.3. branching
18.2.7. Continuous Integration (CI)
18.2.7.1. CI Tools
18.2.7.2. automated deployment
18.2.7.3. automated build
18.2.7.3.1. ten-minute build
18.2.7.4. automated deployment
18.2.7.5. frequent check-in
