MetaphorsWeProgramBy
From SPA Wiki
In this session, we explored the use of metaphor in software development and related practices. A longer description of the intent and process used can be found on the session description page 1. The contents and process of the workshop are founded on a focus group run at EuroPLoP 2006 2.
Status: This page currently (June 2007) contains about all of the raw outputs of the session.
Contents |
Sheets from groups:
Software project as a ship:
- "Your oil tanker of a waterfall project cannot change course easily"
- "your coracle of an agile project is spinning around getting nowhere"
Toilet cleaner <-> sanitation engineer
A metaphor works when it supports my argument at the expense of yours
A metaphor stops working when it becomes a job title
A metaphor doesn't work when it locks you in and limits your thinking
Metaphor context & purpose - focus -
Orchestra pace, discipline, rhythm
Antartic hard project, heroic connotations, team must be right and commited
Film production collaboration, driven by shared vision (storyboard), many roles
Graph of metaphor purpose vs audience
Cards from groups:
Software development as film production
Pink cards
Sequel (version 2) Costume (user interfaces) Supporting actors (dev team, infrastructure team) Movie star (prima donna, essential but need careful management) Visual effects (components, performance) Storyboard (use case, scenario, model) Pre-screen trial viewing (beta) Release date/premier Producer (stakeholder, sponsor) Film editor (Release/?? Processes) Director (technical lead)
Notes
This is expounded by Allan Cooper in 'The Inmates Are Running the Asylum"
or "About Face" (can't remember which one. This seems to fit well with the
rhythm of the software development cycle but is not widely used.
Software team as antartic explorers
Pink cards
Provisions (specialised, must be carried) Icebergs on the way (Hard to even get to the start) On your own (Guerilla, skunkworks, SWAT) Specialised equipment: crampons, sledges Long periods of darkness (!) (changing requirements) South pole vs south magnetic pole (difficult navigation, unclear goals) Self preservation (cost of) (can't worry about others) Poor visibility (hard to see where you are, difficult to plan) Lack of women Strong leader essential (or no progress & freeze to death) Difficult terrain/environment (easy to get lost, high cost of errors) Eat huskies Small team size (can't do logistics for large team) Reliability of equipment (vs huskies) Physically fit (must be experienced, high failure rate for ???)
Software teams as an orchestra (take 1)
Pink cards
Conductor (project manager) Players - specialists (SQL, Java guy, JavaScript guy, opers??) Audience (customer) Soloist(s) (consultant) Staves and notes (notation) Arrangement (score for a performance) Musical score (expressed in notation) Critics/reviewer (auditors/regulators) Performance hall (makes the money out of the performance) Performance (execution) Lead violinist (chief programmer)
Software teams as orchestras (take 2)
Blue/green cards
Specialization (some loud, some soft, some high, some low)
Anonimity (badly paid)
Players work their way up the 'desks' in their section, promoted
to front desk eventually
Concert hall (acoustics)
Require large amounts of arts funding because not profitable
Requires mathematical skill - counting
Appropriate tools well-maintained
Tuning up before a performance
Multi-skilled percussionists can play many instruments
Team organized into sections in which everyone has the same speciality
Most players have a very limited scope for improvisation and
creative input
Frequent practise for less frequent, high-pressure (delivery)
performance
Playing out of tune
"Soloist" who "monopolises" the concert
The "users" have to remain silent until the end of the performance
Aiming for perfection
Conductor (who gives the illusion of being in charge)
Continual practice of basic skills
Pink cards
Orchestras have skilled players - software developers are
often incompetent
Is the performance the software product or the development process?
Software teams as orchestras (take 3)
Blue/green cards
The whole is greater than the sum of the parts, emergent behaviour
Everyone owns their instrument
Co-location
Travel
Tickets
Conductor
Working in a different place every day
Audience
Individual practice
Rehersal
Score/music
Ranking, e.g. 1st violin
Mix of sitting and standing for work
Moving instruments (in vans or on planes)
Concert hall
Manager
Specialisms
Baton
Different lengths of involvement (in a concert or for a run of concerts)
Tuning
Rehersal space
Temprament
Artistic
Programme
Range/variety of instruments
Set layout
Dress code
Interaction
Pink cards
Software system as a ship
Blue/green cards
Sailors (developers) never get sea sick no matter how rough it is
Users as passengers - can get (sea) sick of the system
Heavy loads but slow
Takes a very long time to stop or change direction
- 0 ft. wave (bad timing)
Different kinds of ships/boats - tanker, speed boat, passenger liner,
custom built or off-the-shelf
Captain in charge of everyone in the ship
Small problems can be fixed at sea - big problems require repairs
at port ... or you sink
Life jackets
Plotting course
Work to a schedule, weather disrupts
Distress signals S.O.S
Ships use 'pilots' to get started or to manouver in difficult areas
Regular preventative maintenance
Pink cards
Sinking is usually permanent
Software development as politics
Blue/green cards
Prime minister has responsibility (& power?)
Spin doctors manipulate reporting of what is going on
Complete changes of direction following elections
Dictatorship - socialist planning and control vs
anarchy - little control over the process
Select committees with focused responsibilities and expertise
Checks and balances - executive, legislative, judiciary
Cabinet - each in charge of a ministry
Competing political systems
Law making
Prime minister's question time
Budget cycle departments
Back benchers
Whips - tell people what to do - what opinion to have
(enterprise architects)
Scandal, public eye, media
Pink cards
Parliament seldom refactors the laws
Software project as a journey
Blue/green cards
Planning
Tourism vs work (working on project fun or a chore)
Purpose
Velocity
Destination (completed project)
bookings/tickets (things to organise before start of project)
connections
synchronisation (project management: a number of tasks being carefully synchronised)
timetables (project plan)
movement
mode of travel
starting point (requirements)
refreshments
cost
companions (project team)
strangers
discovery (the unexpected)
accommodation (office space)
Pink cards
Good journeys
bad journeys
Software development as gardening
Green cards
Nurturing (mentoring and coaching)
Silage
Compost (turning debris into something useful - "leftovers" from one project used
elsewhere, e.g. code/tools/ideas)
Moving plants to improve them
Organic (grow the team in-situ)
Staking and tying
Journal (software documentation)
Irrigation (preparing the garden or environment for gardening)
Tending (team management, (code) review)
Pink cards
Gardening can be considered a chore
Gardens are only suitable (thrive in) some environments
Software development as gardening (take 2)
Green cards
Weeding (remove bad practices, remove bad people?)
Feeding (on the job training, paying/rewarding staff)
Greenhouses/cloche (nurturing talent, hot-housing talent, speeding up development by
improving the environment)
Harvesting and picking (outputs)
Propagating %2b sewing (introduce new people, introduce new ideas)
Lawn mowing (straightforward, easy stuff)
Designing
Growing (software developing from beginning to end, project lifecycle)
Killing plants (stifling ideas/innovation, bad code/broken build/failed test)
Pruning (refactoring code, ...top heavy teams to encourage productivity / new growth)
Pink cards
Does this have a place?
Is the garden the system or the team?
Other thoughts
Software development as a cavalry charge Bad project as a train wreck Bad project as a death march Software development as civil engineering x 2 Software development as film production Classes and objects as animals Software development team as a sports team, e.g. football x 3 Program as a building Migration: biplane -> 747 Operating systems as onions Stacks/layering Stacks/queues Software development as architecture/building Software development as archaeology Execution environment as a platform Software as a culture Requirements as mutual education (AL: I like this one) Software as a deliverable Software as a piece of music or poetry Software as art Software dvelopment toolbox Web sites as locations Software evolution Software as an aeroplane Software development as mining Software development as authoring Software education Software as a terrorist network (!) Computer virus/worms/vaccine
Concluding thoughts from groups (three or so words)
- Useful with pitfalls
- Powerful and dangerous
- Useful to communicate complex ideas
- Difficult to perfect
- Tool for thinking
- Illuminating misleading
- Fun and thought provoking
- Though provoking - so what
- Often needs explaining
- Bear in mind
- Use more carefully
- Hard to avoid
Other random notes
Stale metaphor - bootstrap, OK to break down
3 stories at different levels - build round this
Participants
- JaneChandler
- DaveDeNaeyer
- AshleyMcNeile
- BruceAnderson
- DaveThomas
- DanHaywood
- GiovanniAsproni
- NatPryce
- DarrenBishop
- YvesHanoulle
- PeterSumner
- KarelRiha
- DavidPeterson
