How does Design get done on an Agile
Project?
Jeremy D. Miller
Nov 27, 2007
Agile and Software Design
•
•
•
•
•
•
•
•
No Big Design Upfront!
Is Design Dead?
You’re coding without knowing where you’re going?
How is this “Agile” stuff responsible?
What does it mean to “design continuously?”
How does Agile impact the makeup of the team?
How do we make this work?
When do we have to design upfront?
Scenario 1
A Software team is building a new ASP.NET application with
substantial business logic and processing. Do you:
1. Create a web service for the business logic
and make the web application call this web
service
2. Build and deploy the business logic in process
with the web application
Value Proposition of Agile (or Lean)
•
•
•
•
•
Return on Investment
Early and continuous feedback
Capitalize on learning
Flexible delivery options
Sustainable development
Work Vertically by Feature
• Design vertical slices of deliverable functionality
• All design work should be traceable to immediate business
need
 Includes architectural infrastructure
 “Pull” Design versus “Push” Design
• Minimize rework by integrating early




Test early
User feedback early
Deployment feedback early
Shorten the time between doing and verifying
Keep It Simple
• The Simplest Thing that could Possibly Work
 What does “work” mean?
 What does “simple” mean?
• YAGNI – “You aren’t gonna need it”
 Build only what you need right now
 The simple solution may be enough
 Easy to add complexity, hard to remove it
Scenario 2
The new software system requires access to a set of
reference data. This data is fairly static and small to begin
with, but will grow much larger in 9 months. Do you:
1. Build in caching right now
2. Make the access directly to the database
3. Just store this data in a file
The Last Responsible Moment
“…delay commitment until the last responsible moment,
that is, the moment at which failing to make a decision
eliminates an important alternative. “
– Mary Poppendieck
Decide when to Decide
• Make decisions at the right time
• Utilize continuous learning
• Think ahead, yes! Act ahead, no!
 Don’t act on speculative design
 Keep a queue of design ideas and possible refactorings
• Don’t go past the Last Responsible Moment
 Be cognizant of outstanding design decisions
 Some decisions have to be made earlier than others
Delay commitment and complexity
• Simplicity is hard
• Possible effects of abstractions
 Reuse of code and easier development
 Unnecessary complexity
 Changes are more difficult
• Avoid “Architect Hubris”
 If we just build the framework upfront, coding will be easy…
• Harvest Abstraction
 Make any abstraction earn its existence
Reversibility
“If you can easily change your decisions, this means it's less
important to get them right - which makes your life much
simpler. ”
- Martin Fowler
The Limits of Reversibility
• Dependencies on external teams or external experts
• Publicly published interfaces
• Again, decide when to decide!
Designing for Reversibility
• Orthogonal Code
 Separation of Concerns
 Cohesion
 Coupling
• The Single Responsibility Principle
 “A class should have only one reason to change”
• Open Closed Principle
• Don’t Repeat Yourself Principle (DRY)
• Testability
Maximizing Evolutionary Design
• If possible, only divide teams by feature
 Externally facing API’s are NOT reversible
•
•
•
•
Be Cautious when building Frameworks
Persistence Ignorant Domain Models
Delay the Database Model
Presentation / Behavior Separation in the User Interface
Design Together
•
•
•
•
•
•
Socialize the design
Know the why
Collectively challenge the design every day
Talk about the design
Keep the team abreast of changing design strategies
The “This is the way we do it” moment
What do I use for Design?
•
•
•
•
•
•
•
•
•
•
Design Principles
Design Patterns
Test/Behavior Driven Development
Responsibility Driven Design (CRC cards)
Code Smells
Refactoring
Pair Programming
Whiteboard
UML
Design Notebook
Say yes to modeling, but…
•
•
•
•
Travel light
Don’t create any incentive to keep a bad design
Do it together
Expand your intellectual toolbox




UML
CRC cards
ERD
???
• Use precise terminology
• Stop modeling the second you stop learning
Feedback
•
•
•
•
Any Design is theory until proven
“Bubbles don’t crash”
Analysis/Paralysis
If you don’t know what to do next, Spike It!
Refactor Relentlessly
• Design reflectively
• The quality of a design is largely the accumulative sum of
many small decisions
• Clean the dishes after cooking
 Bad names
 Duplication
 Big classes or long methods
• Software entropy is the enemy!
Think and Do
•
•
•
•
•
•
•
Code’n Go == Chaos
The Design Hat never comes off
The Will to Design
Design and coding are conjoined twins
Use solid design principles as you code
Put design strength at the point of attack
Sustainable efforts require good designs
Questions and Discussion
• The Shade Tree Developer –
http://codebetter.com/blogs/jeremy.miller
• jeremydmiller@yahoo.com
Do One Thing at a Time
• The Single Responsibility Principle





“A class should have only one reason to change”
One class, one responsibility
An expression of cohesion
Example: The Blob Class
Example: SingleResponsibilityPrinciple
Open Closed Principle
"Software entities should be open for extension, but closed for
modification.“
- Robert C. Martin
“…the essence of the Open/Closed Principle is being able to
add new functionality to an existing codebase by writing
completely new code with minimal modification of existing
code. ”
Don’t Repeat Yourself
“…every piece of system knowledge should have one
authoritative, unambiguous representation. Every piece of
knowledge in the development of something should have a
single representation.”
 The Pragmatic Programmers
•
•
•
•
Eliminate duplication
Improve cohesion
I only want to tell you this once!
Example: DRY out Session
Test Driven Development
“[Test Driven Development] gives you this sense of keeping
just one ball in the air at once, so you can concentrate on
that ball properly and do a really good job with it.”
- Martin Fowler on TDD
Make your code easy to test
“I don't care how good you think your design is. If I can't walk
in and write a test for an arbitrary method of yours in five
minutes, it’s not as good as you think it is, and whether you
know it or not, you're paying a price for it.”
 Michael Feathers
Isolate the Ugly Stuff
• Some things are hard to test
• Ugly Stuff == Inconvenient while unit testing




The Database
Active Directory
Web Services
Messaging
• Model View Presenter as an example
 The actual user interface is hard to test
 Use Model View Presenter to decouple code from the user interface
machinery
• Dependency Inversion Principle
 Code to the interface, not the implementation
Expand the Creamy Center
Graphic from Jay Flowers
Push, Don’t Pull
• Example: When is now?
• Inversion of Control
 Don’t call me, I’ll call you
 Example: The Translator
 Database Mapper
• Dependency Injection
 “new()” is a form of tight coupling
 Example: Constructor Injection
Test Small Before Testing Big
• Code from the bottom up
• Oh no! How do all these pieces fit together?
 Don’t care (for now)
 What do you know how to do?
• Short term value proposition of TDD:
 Save more time in debugging than you spend in unit testing
Example: Supply Chain Routing
• Determine the best way to route requests from the factory
lines for parts
• Correlate data from three different sources of information
into “shelves”
• Apply a complex series of business rules against the data
to select the best part channel (part, inventory source, and
factory line destination)
Keep a Short Tail
• Can you get there from here?
• Aerosmith and Roadies
• Test by Measuring What You are Trying to Test!
 Example: InvoiceScreenCreator
• Isolate the Churn
• Whenever you can, keep the database on the sidelines
Establish a Maintainable Software Ecosystem
•
•
•
•
Change enablers
Feedback loops
Test automation
Continuous Integration