Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
EOIN WOODS
ENDAVA
@eoinwoodz
20160525.2
Capturing
Design
The Problem
Why
Document
Design?
How?
People move
jobs
Organisations
change
Memories Fade
Priorities
change
Knowledge
Attrition
Knowledge
Attrition
• “untouchable” code
• mysteriously failing tests
• odd decisions from long ago
• new extensions are a...
Reducing
Knowledge Loss
Why we need
more than code
How design
information helps
Limitations of
code
The truth not the whole truth
Many people don’t read code
Organised for machines
Mismatch with communi...
Design as a
Record
Design for
Communication
Design for
Analysis
Using Design
Information
•
•
•
•
•
•
•
•
Effective
Design
Artefacts
Principles
Pragmatics
• M
• U
• S
• I
• C
• AUDIENCE
• PURPOSE
“MUSIC”
• PRINCIPLES
•
• DECISIONS
•
• ELEMENTS RESPONSIBILITIES INTERACTIONS
•
•
•
• WORK IN PROGRESS
“Indexed” and “checked” are Nat Pryce’s suggestions to add to
the “minimal”, “significant”, “usable” se...
• WHO
• TECHNICAL
• KNOW
• UNDERSTAND
• WHAT
• TASKS
• INFORMATION
• CHARACTERISTICS
•
•
•
•
•
•
•
Low
Fidelity
High
Fidelity
Abstract
Detailed
Fidelity
Cost
Naming
Linking
Embedding
Shared
Versioning
Architecturally
Evident Coding
Shared Tooling
But beware limits!
George Fairbanks – Just Enough Software Architecture
•
LINK CODE DOCUMENTATION
•
• RECENT APPROACH
•
• ANNOTATE CODE
• EXTENDED MODEL
https://www.structurizr.com/
Effort
“Quality”
Morning
Standup
Team Wiki
Review
Documents
Long-term
record
Regulatory
Deliverable
Product
Documentation
Database
Calculation Engine
Batch Processor
Change Notifier
User Interface Services
Little and Often
Create a
commons
Find evidence
of use
RECORD
• FUTURE
NEED TO KNOW
• LONGEVITY
• SEMANTICS
• LINK
• ORGANISE
COMMUNICATE
• WHO WHY
• CLARITY
• THROW IT AWAY
• CODE STORY
• WHOLE STORY
• KNOWLEDGE ATTRITION
• RECORD COMMUNICATE
• PRINCIPLES PRAGMATICS
RESEARCH DESIGNERS
ATTENTION
SURVEY
Eoin Woods
CTO
Endava
@eoinwoodz
www.eoinwoods.info
eoin.woods@endava.com
•
•
•
http://thumbs.dreamstime.com/z/techn
ology-blueprints-23277500.jpg
• Design for Communication -
http://optymyze.com/
Capturing Design (When you really have to)
Capturing Design (When you really have to)
Upcoming SlideShare
Loading in …5
×

Capturing Design (When you really have to)

110 views

Published on

A presentation at XP2016 to discuss how to capture design information, when this is valuable, what to capture and how to do it effectively.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Capturing Design (When you really have to)

  1. 1. EOIN WOODS ENDAVA @eoinwoodz 20160525.2
  2. 2. Capturing Design The Problem Why Document Design? How?
  3. 3. People move jobs Organisations change Memories Fade Priorities change Knowledge Attrition
  4. 4. Knowledge Attrition • “untouchable” code • mysteriously failing tests • odd decisions from long ago • new extensions are always an adventure!
  5. 5. Reducing Knowledge Loss Why we need more than code How design information helps
  6. 6. Limitations of code The truth not the whole truth Many people don’t read code Organised for machines Mismatch with communication
  7. 7. Design as a Record Design for Communication Design for Analysis Using Design Information
  8. 8. • • • •
  9. 9. • • • •
  10. 10. Effective Design Artefacts Principles Pragmatics
  11. 11. • M • U • S • I • C • AUDIENCE • PURPOSE “MUSIC”
  12. 12. • PRINCIPLES • • DECISIONS • • ELEMENTS RESPONSIBILITIES INTERACTIONS • • •
  13. 13. • WORK IN PROGRESS “Indexed” and “checked” are Nat Pryce’s suggestions to add to the “minimal”, “significant”, “usable” set I proposed. These look important to me, but I haven’t thought them through yet.
  14. 14. • WHO • TECHNICAL • KNOW • UNDERSTAND • WHAT • TASKS • INFORMATION • CHARACTERISTICS
  15. 15. • • • • • • •
  16. 16. Low Fidelity High Fidelity Abstract Detailed
  17. 17. Fidelity Cost Naming Linking Embedding Shared Versioning Architecturally Evident Coding Shared Tooling But beware limits!
  18. 18. George Fairbanks – Just Enough Software Architecture
  19. 19. • LINK CODE DOCUMENTATION • • RECENT APPROACH • • ANNOTATE CODE • EXTENDED MODEL
  20. 20. https://www.structurizr.com/
  21. 21. Effort “Quality” Morning Standup Team Wiki Review Documents Long-term record Regulatory Deliverable Product Documentation
  22. 22. Database Calculation Engine Batch Processor Change Notifier User Interface Services
  23. 23. Little and Often Create a commons Find evidence of use
  24. 24. RECORD • FUTURE NEED TO KNOW • LONGEVITY • SEMANTICS • LINK • ORGANISE COMMUNICATE • WHO WHY • CLARITY • THROW IT AWAY
  25. 25. • CODE STORY • WHOLE STORY • KNOWLEDGE ATTRITION • RECORD COMMUNICATE • PRINCIPLES PRAGMATICS
  26. 26. RESEARCH DESIGNERS ATTENTION SURVEY
  27. 27. Eoin Woods CTO Endava @eoinwoodz www.eoinwoods.info eoin.woods@endava.com
  28. 28. • • • http://thumbs.dreamstime.com/z/techn ology-blueprints-23277500.jpg • Design for Communication - http://optymyze.com/

×