takes time for a team to form

Magical about a gelled team

Team should not be formed around availability towork on a project

Team should be first class decesion

most developers progress this way

very slow, very hard, not fun

10+ years of experience

lead of multiple projects

coordinate multiple teams

Maintain technical role by reading, studying,practicing, doing and teaching

Trained, competent and energetic

Learn how to work well in teams and becometeam leaders

Knowledgeable about current technology buttypically lack experience w/ many diversesystems

Teachers

Graduates start here

Closely supervised by journeymen

Need intense pair programing

Ought to last a year

someone who works quickly, but withoutrushing, who provides reasonoableestimates and meets commitments

knows when to say no, but tries hard to say yes

a professional

can't convince people to be crafstmen

can't convince them to accept craftmanship

Acceptance is not so much rational as muchemotional

Make craftsmanship observable

Open Source tools are usually your best option

Enterprise controls usually suck

2008 switched to GIT

VI

EMACS

Eclipse/IntelliJ

Start small, grow as needed

Bob is using Pivotal Tracker

Jenkins

If the build fails, stop the presses and resolvethe issue

JUnit

RSPEC foro Ruby

NUnit for .Net

Midje for Clojure

CppUTest for C(++)

FitNesse (written by Bob)

Others

Not worth it

Assumes the problem is code/design

No great diagramming language today thatsolves real problems

Impossible?

QA Should Find Nothing!

All code should be covered with automated unittests

You must be able to make changes withoutexorbitant costs

Merciless refactoring

40 hours to solve your employers problems

20 hours on your career

56 hours for sleep

52 hours for everything else

Design patterns

Design principles

Methods

Disciplines

Artificats

Kata

Read a couple books on the new topic

Spend some time with the experts and try tounderstand their principles and values

Don't allow anyone to lie to try to make the teamsound better, its not beneficial to anyone, theproject, the company or the customer

It applies you and your team to a newcommitment that no one really thinks isplausible

A professional is already trying, there is nomagic pixie dust to make us work better ondemand

Say no to trying

I could try to change lead in to gold

If your boss is not taking 'no' seriously, make itclear his/her boss needs to be told the truth, oryou will tell them

Say you'll do it

Mean it

Actually do it

"Yeah, we really need to get some new routers"

Ask a team members to run tests >"Sure. I hopeto get to it by the end of the day"

Management to the team >"We have to movefaster"

Signs of non commitment

"I will... by..."

Bad Excuses

Don't allow vagueness

Necessary

Huge Time Wasters

~$200/hr/attendee

need to use your time wisely

don't accept meetings unless it is a meeting forwhich your participation is immediately andsignificantly necessary to the job your doing now

Your management should help keep you out ofunnecessary meetings

When the meeting gets boring, leave

remaining in a meeting that has become awaste of time for you and you can no longersignificantly contribute is unprofessional

When invited, try to get the details of agendaand how much time is alloted for them

When meeting gets side tracked ask the newtopic be tabled and the agenda be followed

Run experiments or do some simulation ormodeling

If one path works out great, otherwise you can godown the other path

Pick a time frame in which to decide if path'sneed to change

'This is how he wants it so this is how he willget it'

have the team vote

long walk

conversation w/ friends

meditate

power nap

listen to podcast

bike riding

carpentry

building models

gardening

politely decline all interruptions to get back tothem within 25 min

Convincing yourself something else is moreimportant to avoid doing the real work

Unprofessional Don't do!

Commitment

Estimate

no commitment is implied

Missing an estimate is not dishonorable

An Estimate is a probability distribution

Trivariate analysis

Expected duration

Standard deviation

Example

Sequence Calculations

Flying Fingers

Planning Poker

Affinity Estimation

Trivariate Estimates

avoid committing to deadlines we can't meet

help the business meet goals set by others butdon't take ownership of the commitment

"quick and dirty" is an oxymoron

How you behave in crisis shows what you trulybelieve in

Choose the methods you feel comfortablefollowing in a crisis, then follow them all thetime.

Don't stay up all night, sit and frett, or rush,none of these things will help solve theproblems

Slow down and think the problem through

Let your team and superiors know you are introuble

Discuss the best plans to get out of trouble, askfor their input

Avoid creating surprises for anyone

TDD more

Refactor harder

Pair Program!

Same analogy for driving, driving needs yourfocus, don't drive when distracted

Learn how to manage your time with thoseproblems. Spend some blocks of timethroughout the day working on both to easeyour mind and allow you to code

True the zone will allow you to write more codehowever that's not an indicator your moreproductive

The zone causes tunnel vision and causes you tolose sight of the big picture

Pair programming makes it near impossible toenter the zone

Avoid listening to music and headphones thisdoesn't usually help you code, it helps you stayin the zone which is undesired

The zone causes you to be rude to interruptions extremely unprofessional to be rude

Pair Program

Do this with TDD

Layers constantly retrying cases, surgeons reopening uppatients are unprofessional

Worst unprofessionalism of all

your responsibility to be available to help eachother

unprofessional to sequester yourself in acubicle and refuse the queries of others

If needed set office hours

Offer to help, don't wait to be asked

Developers don't have to defend TDD

tens of unit tests written a day makes me certainthe code works when I wrote it and still workstoday

Proven to reduce the amount of bugsdramatically

Bad code is scary to fix without unit tests sooften it doesn't get fixed

When developers lose their fear of cleaning,they clean

Each unit test defines how the system shouldbe used

Implicit, constantly updating, constantly addeddocumentation

Following the laws forces you to be able to testyour code

If tests are written after the code is written, it'swritten defensively and will force theimplementation to work

You can even write bad tests

professionals should never follow a disciplinewhen that discipline does more harm than good

Attempt to practice so much to reach perfection

You already know the solution, but practicing theproblem solving motions of TDD is the goal

The Bowling Game

Integer Square Root

Prime Factors

Word Wrap

Pingpong pair programming pattern

When you both really know the kata

speed & memory

Make it competitive and fun

People rotate through while the code isprojected on the wall

Can go in order, people can skip, movearound, etc no specific rules just with morepeople

Both want a precision that simply cannot beachieved

requirements when implemented often aren'treally what is desired in the end

why?

analysts test happy paths

QA tests unhappy paths

Should not be the same developer whoimplemented it

X has to run in under 2 seconds

Negotiate on average 2 seconds

"not what requirements say"

realistically though it's the only way

run test 15 times and average is less than 2seconds

test things very differently

But probably still will

NOT automated, nor scripted

NOT written test plan of this kind of testing

Some teams will have a specialist do this,others will declare a day or two of 'bug hunting'to bang on the system

Ultimate integration tests across the entiresystem

NOT test business rules

written by system architects and technical leads

choreography tests how well theassembly of components dancestogether

NOT test business rules

Written by system architects or lead designersof the system

typically not executed as part of CI

Acceptance tests of specific components

Written by QA and business with assistancefrom development

apart of continuous integration suite

written by programmers for programmers

as close to 100%, generally in the 90s of truecoverage

collaborate with managers, business analysts,testers and other team members to understand

understand the business and keep it afloat

Programmers should never own a piece of code

Break down all walls of code ownership andhave the team own the code

Many programmeres dislike the idea

clearly the most efficient way to solve theproblem

Professionals Pair

need to hear frustrated mutters, serendipitouscommunication

And its unlikely you work better when you workalone