Iteration Podcast

Before The Project

Jul 27 '18

Chapter 7 - Before The Project

Season 2 Episode 10

John: Welcome to Iteration: A weekly podcast about programming, development, and
design through the lens of amazing books, chapter-by-chapter.

JP: Welcome to PART 1 of Chapter 7: "Before The Project."

Starting a project can be a daunting task. There are a lot of unknowns and you
might not know when you should start. We're going to talk about some of the
things that will guide you when starting a project from scratch. Our focus will
be gathering and understanding requirements

For me, this is great because though I work at OL, I might be taking on a
freelance client soon!

51 - Don't Gather Requirements - Dig For Them

John:

"Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away...."

Requirements rarely lie on the surface. They're buried deep beneath the layers
of assumptions, misconceptions, and politics

JP: You can't just "gather" requirements as if they exist. You must do RESEARCH.
Remember that you're solving business problems

52 - Work with a User to Think like a user

It's the best way to gain insight into how the system will really be used

JP: OBSERVE users for a week - this is much different than "thinking" like a
user. I think that if you do the latter, you end up with preconceived notions
based on your own assumptions.

John:

"It's important to discover the underlying reason why users do a particular thing, rather than just the way they currently do it."

Learn understand business processes development
Consider the politics (You write code + people get fired)

53 - Abstractions Live Longer than Details

John:

"...the simplest statement that accurately reflects the business need is best."

John: Distilling real-world processes and people down into the most elegant and concise definition

Invest in the abstraction, not the implementation. Abstractions can survive
the barrage of changes from different implementations and new technologies

Requirements are not architecture. Requirements are not design, nor are they
the user interface. Requirements are need

JP: Don't sweat implementation details. Requirements should be abstract

54 - Use a Project Glossary

Create and maintain a single source of all the specific terms and vocabulary
for a project

JP: Create a literal glossary so that you and stakeholders can have a
UBIQUITOUS LANGUAGE #domaindrivendesign - i.e. "client" and "customer"
might be the same - they might be different.

Also - you want this to live in a document that's shared. Don't know how serious
that is but this is what the author's recommend for serious projects

55 - Don't think outside the box - find the box

John:

Gordius, the King of Phrygia, once tied a knot that no one could untie. It was said that he who solved the riddle of the Gordian Knot would rule all of Asia. So along comes Alexander the Great, who chops the knot to bits with his sword. Just a little different interpretation of the requirements, that's all... and he did end up ruling most of Asia.

When faced with an impossible problem, identify the real constraints. Ask
yourself: "Does it have to be done this way? Does it have to be done at all?"

JP: Find the constraints of the box so that you can solve the problem at hand.
You have to think of every possible avenue so that you don't dismiss potential
solutions. I really like this:

Consider the Trojan horse - a novel solution to an intractable problem. How do
you get troops into a walled city without being discovered? You can be that
"through the front door" was initially dismissed as suicide.

Think of the most restrictive constraints first, and fit the remaining
constraints within them.

Too many quotes alert

Many times a reinterpretation of the requirements can make a whole set of
problems go away [...]. All you need are the real constraints, the misleading
constraints, and the wisdom to know the difference.