Transcript Software Creation Communication

Software Creation
Communication
Agile Principles applied to software
projects
Craft, Community, Pride, Learning, Creativity,
Communication, etc.
Efficiency
Etc., etc., etc.
Psychology
Sociology
Philosophy
Physics
Physics
Biology
Business
Computer Science
Silos of Knowledge
Agile Manifesto
Manifesto for Agile Software Development
 We are uncovering better ways of developing
software by doing it and helping others do it.
 Through this work we have come to value:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
 That is, while there is value in the items on
the right, we value the items on the left more.
http://agilemanifesto.org/
Authors of Agile Manifesto
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Note: Most of this presentation is based upon the work of Alistair
Cockburn’s Agile Software Development
Is creating software…
Engineering?
 Science?
 Art?
 Development?
 Construction?
 Something else?
 Does it matter?

It does matter!

The way we think about anything is
constrained by

The mental frames we use


The language we use to describe it (connotations)



Frames trump facts. Frames will stay and the facts will
bounce off. -George Lakoff
Tax relief vs. tax deferment
Death tax vs. inheritance tax
Actions and results CAN differ depending on
your viewpoint!
Parsing Experience

When we experience something, we
parse it into separate, meaningful chunks
OR

?
When we parse according to one pattern
and later put the pieces back together,
we get a distorted, simplified result!
Conclusions…
Any complex shape can be parsed
according to different patterns
 Our perception of “what is there”
proceeds in different directions
depending on how we separate elements
 What we notice is biased by the
vocabulary we start with

Impossibility of Communication?

Information received is determined by what
happens inside the receiver, not just the
information the sender is trying to impart
 Stimulus: Yell “Fire” in a crowded theater




Response A: someone hears, and exits safely
Response B: someone hears, and panics
Response C: someone is asleep, and doesn’t hear
Response D: someone doesn’t speak English, and
doesn’t understand
Impossibility of Communication?
Communication is NEVER perfect and
complete
 The more a person is different from you,
the SMALLER the communication gap
he can jump
 No matter how much you back it up,
there is ALWAYS someone who will not
understand.

Impossibility of Communication?
From Steve McConnell, Rapid Development
Conclusion…

We can never hope to completely specify the
requirement or the design

Experience,
Explicit Communication

Experience,
Explicit Communication

The Golden Rule: The task on a project is not
to try for complete communication, but to
manage the incompleteness
Levels of Listening

Level 1: Following




Level 2: Detaching




Need explicit procedures/instructions
Detailed manuals and documentation provide safety
RUP – Rational Unified Process
Can adapt procedures to the situation
Understands where procedures break down
The Art of Computer Programming
Level 3: Fluent



Irrelevant if following a procedure
Understands the desired end effect and will make it work
despite process or tools
The Pragmatic Programmer
Levels of Listening

The Zen of Level 3….
“Do whatever works”
 “When you are really doing it, you are
unaware you are doing it”
 “Use a technique so long as it is doing some
good”

To someone fluent – makes sense
 To someone detaching – confusing
 To someone following - useless

Conclusions…

Consider the level of your team

Is it following, detached, or fluent? Is it some
combination of the three?
The mystery is that we can’t get perfect
communication. The answer to the mystery is
that we don’t need perfect communication!
 Remember the Golden Rule: manage the
incompleteness. That is, you just need to get
close enough, often enough.

Think Outside the Box
Let’s
compare software
development to…a group
writing epic poetry together!
Think Outside the Box

Who are the players?
The people who ordered the poem
 Key poem designers

Began as a one person project, but the poet, in
usual fashion, promises MUCH more than she
can deliver!
 So, adds other people fairly good at poetry, and
takes the role as ‘lead’ poet
 Still can’t get it done, so now they get desperate
– they add friends and neighbors, beginners
NOT good at poetry!

Think Outside the Box

As more people are added, many of whom are
inexperienced, communication and coordination
becomes a HUGE problem
 One person was good at descriptive passages, one
was good at the gory bits, etc.
 The lead poet is now so busy coordinating and
checking, she no longer has time to write poetry!
 A couple of people wrote pages and pages of material
describing the antagonists, way more than needed –
that is the part they liked writing about.
 Another few people kept revising and revising, never
satisfied with their work
Think Outside the Box
As time progressed, the group got
desperate and added even MORE
people.
 Communications were horrible, no one
had a current copy of the poem, and no
one knew the actual state of the poem

Conclusions…
What does this say about software
development?
 Almost every project of any size has
temperamental geniuses and average or
below workers, hard requirements, and
communication pressures.
 Why do we expect software development
to be any different from group epic
poetry writing?

So Then, What is Programming?

Normally thought of as…




But it is ALSO…





Solitary
Inspiration-based
Logical activity
A group engineering activity
Mathematical
A craft
A mystical act of creation
It’s creation is sensitive to tools, but its quality
is independent of tools