Before The Project

Episode Summary

This week we talk through Chapter 7 all about starting projects. Gathering requirements, working with users, project glossaries and more to help get projects off the ground.

Episode Notes

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


"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.


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

53 - Abstractions Live Longer than Details


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

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


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.

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.


JP: Swift - The Big Nerd Ranch Guide. Plenty of reasons why I want to learn

John: Pusher - Websockets as a service.