Software Creation Communication

Agile Principles applied to software projects

Silos of KnowledgeC

ompu

ter

Sci

ence

Bus

ines

s

Bio

logy

Phy

sics

Phy

sics

Phi

loso

phy

Soc

iolo

gy

Psy

chol

ogy

Etc

., e

tc.,

etc

.

Craft, Community, Pride, Learning, Creativity, Communication, etc.

Eff

icie

ncy

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 BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim Highsmith

Andrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave 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

Frames trump facts. Frames will stay and the facts will bounce off. -George Lakoff

The language we use to describe it (connotations) Tax relief vs. tax deferment Death tax vs. inheritance tax

Actions and results CAN differ depending on your viewpoint!

When we experience something, we parse it into separate, meaningful chunks

When we parse according to one pattern and later put the pieces back together, we get a distorted, simplified result!

Parsing Experience

OR ?

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

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

Conclusion…

Levels of Listening

Level 1: Following Need explicit procedures/instructions Detailed manuals and documentation provide safety RUP – Rational Unified Process

Level 2: Detaching 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 senseTo someone detaching – confusingTo 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 poemKey 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… Solitary Inspiration-based Logical activity

But it is ALSO… 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