Project PatternsBreaking practices

By Fred Lee

(with tons of inspiration from 37signals)

Project Patterns

General concepts we shall adhere to

Not hard and fast rules

Good projects are flexible and adaptable.

We shall take responsibility

Live for nothing, or die for something.

Reject mediocre requirements

Interpretation 101screenshot != requirements

Documentsthis == Time.lots == Change.lots == Time.waste

Touch Stakeholderstouch => agreement == happy == awesome

Challenge “need”

“need”, really?

“Everyone else is doing it.”

“The old system did it that way.”

“In order to . . .”

“It should be easy, so . . .”

“Eva Longoria is wearing Uggs.”

“The Macbook Air is so light.”

Needthis == Feature.creep == Project.done.never

Decisions are temporary

Break it downFear == Application.bad

Break it down when

It smells

Can’t remember why

It can’t be broughten up (yeah, that’s a word)

Focus on what does not change

Death and Taxes99.99% sure

What won’t change

Performance and Speed

Good UI

Good design

Client’s core business functions

Desire to make a lot of money

Remove abstractions

Abstractions

Documents

Drawings

PS prototypes

Emails

Meetings

Discussions

Wood block => awesomeGet to the point faster: IDEO and rapid prototyping

Project Patterns

Wrap it up

Reject mediocre requirements

Challenge “need”

Decisions are temporary

Focus on what does not change

Remove abstractions

The Fix: Agile PracticesRequirements, “needs”, and what does not change

Behavior Driven Development (BDD)

Features

Stories

Scenarios

Specs

Temporary Decisions

Short, short, short iterations

Remove Abstractions

Rapid prototypes