Agile Software Development:

1
Agile Software Development

• Principles, Patterns, and Practices
• A definition of the craft of software development.

2
What is our craft?

• The craft of software development has made slow,
  but steady progress over the last four decades.
• We have continuously added new and valuable tools
  to our toolkit.
• But, until recently, our craft was not well
  defined.

3
1960s Modular Programming

• We learned that programs were better when broken
  up into pieces.
• Pathology No module can be more than 500
  bytes.

4
1970s Structure

• Structured Programming
• Structured Analysis
• Structured Design
• Principles
• Cohesion, Coupling
• Pathologies
• Waterfall
• Dependence upon diagrams
• Dependence upon process.

5
1980s Objects

• OOP, OOD, OOA???
• Principles
• Simplicity Its just an object
• Encapsulation enhanced modularity
• Pathologies
• The search for analysis.
• The search for the true artifacts.
• Notation wars.
• Real world modeling.

6
1990s OOD!

• Principles.
• Dependency Management SRP, OCP, LSP, DIP, ISP,
  REP, CRP, CCP, ADP, SDP, SAP.
• Patterns
• GOF, POSA, Analysis Patterns.
• UML.
• Finally, a common notation.
• Process?
• Iterative? RUP? Objectory? Waterfall? Spiral?
  CMM?

7
1990s What are the best practices?

• How do I use Patterns?
• How do I use Principles?
• Should everything derive from an interface?
• Is this a good model of the real world?
• Which process do I use?
• Is this a good domain model?
• Is my analysis document complete?
• Are my use cases right?
• Should I make sequence diagrams from all my use
  cases?

8
2000s Agile Practices

• XP!
• A specific set of practices.
• Pair Programming, Test First, Collective
  Ownership, Continuous Integration, The Planning
  Game, Refactoring
• Agile.
• A conceptual framework for practices.
• People over process.
• Code over documents.
• Negotiation over contracts.
• Adaptability over dogma.

9
PPP The synthesis.

• Our craft has these three elements
• Principles
• Patterns
• Practices.
• Their synthesis is a greater whole!
• It is the definition of our craft.

10
The Craft of Agile Development

• The synthesis of PPP gives our craft a
  definition.
• Prior to this, we were developers, but we didnt
  know what developers did.
• Now we know what we do, and how we do it.

11
The interplay of PPP

• Practices guide our daily work.
• Practices help us to detect problems.
• It is hard to write a test for this module.
• Principles help us to diagnose problems.
• The module is too coupled to other modules
  because it violates the DIP.
• Patterns help us to solve them.
• Strategy pattern inserts an interface and inverts
  the dependency.

12
Now we know what we do

• Agile Craftsmen
• Work in pairs.
• Write tests before code.
• Plan with customers.
• Work in very short iterations.
• Use acceptance tests.
• Keep the code clean.
• Keep the code integrated.
• Communicate obsessively.

13
We know what good design is.

• Modules with a single source of change (SRP)
• Modules that are extensible without modification
  (OCP)
• Substitutable Interfaces (LSP)
• Dependence upon abstraction (DIP)
• Interfaces related to clients (ISP)

14
We know solutions to common problems.

• Strategy
• Visitor
• Factory
• Bridge
• Composite
• Etc.

15
We also have something else

• Knowing what we do, and how we do it gives us the
  ability to
• take pride in our work, and in the way that we
  work.

16
Pride in work v.s. workmanship

• Many of us could take pride in the programs we
  have written I.e. the work.
• Though most of us know what its like to be
  embarrassed.
• But fewer of us could take pride in the way that
  work was done I.e. the workmanship.
• Somehow it just all worked out.

17
Pride in workmanship.

• We wrote out code test first. Every line of code
  is supported with a test.
• We refactored. We never let the sun set on bad
  code.
• We planned, every two weeks.
• We integrated many times a day.
• We kept all our acceptance tests passing.
• We communicated with the customer daily.

18
Pride in Work.

• Pride in workmanship leads to work well done.
• We take the time necessary to
• Keep our code clean.
• Make sure our code is a simple and expressive as
  it can be.

19
An Agile Craftsman values

• Contribution over authorship.
• Collaboration over cleverness.
• Learning over knowing.
• Delivering over Process.
• Simplicity over Generality
• Cleanliness over being prolific.

20
Practices are tools, not laws.

• Pairing helps, so we do it. But we dont have to
  do it all the time.
• Test first helps, so we do it.
• Collective ownership helps, so we do it.
• But we are not constrained.

21
Principles are tools, not laws.

• Not all dependencies need inversion.
• Not all derivatives need to be substitutable
• Not all interfaces need to belong to their
  clients.
• Not all packages should be on the main sequence.

22
Patterns are tools, not laws.

• Not all objects should be created by factories.
• Not all reports should be generated by Visitors.
• Not all choices should be represented by
  strategies.
• Not all databases should be accessed through
  proxies.

23
Our craft is to use these tools to deliver.

• We use pairing
• We use OCP
• We use Visitor
• We use them to deliver.
• We take pride in what we deliver.
• We take pride in how we deliver.

24
PPP The book

• Section I Agile Practices
• Section II Agile Design
• Section III Payroll Case Study
• Section IV Packaging the Payroll System
• Section V The Weather Station Case Study
• Section VI The ETS Case Study
• Appendix A UML Notation I
• Appendix B UML Notation II
• Appendix C A Tale of two Companies
• Appendix D The Source Code is the Design.

25
Section I Agile Practices

• Chapter 1 Agile Practices
• Chapter 2 Overview of XP
• Chapter 3 Planning
• Chapter 4 Testing
• Chapter 5 Refactoring
• Chapter 6 A Programming Episode

26
Section II Agile Design

• Chapter 7 What is Agile Design
• Chapter 8 Single Responsibility Principle
• Chapter 9 Open Closed Principle
• Chapter 10 Liskov Substitution Principle
• Chapter 11 Dependency Inversion Principle
• Chapter 12 Interface Segregation Principle

27
Section III Payroll Case Study

• Chapter13 Command and Active Object
• Chapter 14 Template Method and Strategy
• Chapter 15 Façade and Mediator
• Chapter 16 Singleton and Monostate
• Chapter 17 Null Object
• Chapter 18 Payroll, Iteration 1.
• Chapter 19 Payroll, Implementation.

28
Section IV Packaging the Payroll System

• Chapter 20 Principles of Package Design
• Chapter 21 Factory
• Chapter 22 Payroll, Part 2.

29
Section V The Weather Station Case Study

• Chapter 23 Composite
• Chapter 24 Observer
• Chapter 25 Abstract Server
• Chapter 26 Proxy and Stairway to Heaven.
• Chapter 27 The Weather Station Case Study

30
Section VI The ETS Case Study

• Chapter 28 Visitor
• Chapter 29 State
• Chapter 30 The ETS Framework.

31
What the laptop saw of the author