Mary Poppendieck : Technical Excellense

"The relentless pursuit of simplicity"
Book: Lean SW development (Poppendick)

All talks from Mary are on chapters from the book

The question: How do we deal with Complexity?
The complexity (and mess)of software is often invisible from the outside,

The answer: Divide and conquer

But how to divide - there are several options?
- Divide by Structure
(Divide by Hierarchy/order of execution)
Historical perspective on various ideas on how to structure. "Structured programming - Quality by construction", "Top-Down programming - Step-Wise Integration",
xUnit testing is an good answer to this approach, but n

- Divide by responsibility
(Divide by Matching the Domain)

- Divide by process
Example: The Waterfall process.
This has never worked well.
- The cost of debugging
- The cost of integration
- The cost of task switching
- The cost of delay
- The cost of complexity (to change)

- Divide by Value
(Design by objectives)

Let us not confuse the differences between Project Management and Systems Development

Project Management (Changes over time)
- Requirements
- Quality of testing
- Scope conrol
- Maturity levels
- Resources
- Timeboxes

Systems Development (Robust over time)
- Low dependency architecture
- Quality of construction
- Respect for complexity
- Technical disciplines
- Technical expertise
- Learning/feedback cycle

Pay attention to the robust part!

- Divide by responsibility and value = The agile idea.

Nice slide on the various "phases" and what to focus on in these (Goals/Roadmap, Iteration planning, Design and Implement, Delivery)

Emphasizes the benefit of the practice of writing tests first! Including xUnit tests and
Acceptance Tests, Stress tests, Presentation layer tests

Displayed a matrix with the different test types, proposed automation level and frequency + the two different perspectives of "Testing to specification" and "Testing to Failure"


Refactoring
- Why do we need to refactor?
Because we practice JustInTimeNOT JustInCase. This reduces complexity.
Refactor: Simplify the code base - eliminate smells

Need a policy to drive this - E.g. We will have clean and readable code

4 criteria for simplicity
- passes the test
- reveals all of the intentions
- no duplication
- fewest number of classes/methods


Respect for complexity
- Accept that change is not the enemy
- Recognize that complexity is the enemy
- Simplify before automating
- Write less code - essential simplicity

Example from Amazon.com
Did not consider the scale when they started..
Started transformation to services in 2000 - transform completed in 2008..
- each service is owned by a small team (about 8 people). No service is allowed to be bigger than possible to manage by this team.
The team is responsible for everything related to the service
(spec, dev, deploy, support, everything..)
SLA's and contracts towards other services
Very little standardization across

People talk and cooperate across teams, but is allowed and encouraged to make your own decisions



Technical discipline

Mistake proofing
- Design/code reviews
- Config/version management
- One click builds (private and public)
- CI
- Automated Unit Tests
- Automated Acceptance tests
- STOP if the tests dont pass
- system testing with eatch iteration
- automated release/install
- escaped defect analysis & feedback

Simplicity
- Low dependency architecture
- Development standards (coding, naming, logging, security, usability)
- Standard tools
- Refactoring

Technical expertise matter. Example from the pilot that landed in the Hudson river.

Must develop a practice to keep improving
- Realise what you want to improve
- Get exercises to improve them
- Focus on pushing the limits
- Practice regurlary and intensely

Create competencies leaders that focuses on evolving and nurturing peoples competences.
This is not the same as the Product Champion (example: Music Teacher VS The Maestro)