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.
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!
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
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."
John:
"...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
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
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.
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
Swift.