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