Chapter 7 (pt. 2) - Steve Jobs teaches us how to wash clothes

Season 2 Episode 12

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 2 of Chapter 7: "Before The Project"

56 - Start When You're Ready

You've been building experience all your life. Don't ignore
nagging doubts.

JP: Follow your instincts when starting a project - but don't
procrastinate - you can do this by prototyping. Proof of concepts are nice
when you tackle the "hard" thing first. Prototype to discover

John: Prototype, prototype!

"as the prototype progresses you may have one of those moments of revelation when you suddenly realize that some basic premise was wrong."

57 - Some Things Are Better Done than Described

Don't fall into the specification spiral - at some point you need to start
coding.

JP: "Program specification is the process of taking a requirement and reducing
it down to the point where a programmer's skill can take over." -

John:

"natural language is really not up to the job."

• John: Even if it's just a screen recording and an ugly sketch prototype - manually scrolling around - WAAAY better than a written requriment doc. I rarely define work through written requirments.

more than 1 bullet point alert

• specs will never capture every detail and nuance of the system and it's
  important to recognize this
• "A design that leaves the coder no room for interpretation robs the
  programming effort of any skill and art" - you may unearth some insights by
  beginning to code
• "Distrust environments where requirements are gathered, specifications are
  written, and then coding starts, all in isolation."
  • there should be no artificial boundaries
  • a healthy dev process encourages feedback from implementation and testing
    into the spec process
• there is a point of diminishing returns when specs get too details
• this reminds me of the early days of Whiz when I was a designer. everything
  was terribly isolated

58 - Don't Be a Slave to Formal Methods

Don't blindly adopt any technique without putting it into the context of your
development practices and capabilities

This shows how dated the book is. examples of formal methods: CASE tools,
waterfall development, "the spiral model", to today's UML diagrams.

If this were written today, we'd talk about lean methodology, agile development,
SCRUM

• don't get caught up in methodology. this is bad because it encourages
  isolation. "us vs. them" mentality between designers and programmers. the
  process should be more collaborative
• that's not to say you SHOULDN'T use formal methods. just remember that they're
  another tool

You should work constantly to refine and improve your process

59 - Costly Tools Don't Produce Better Designs

Beware of vendor hype, industry dogma, and the aura of the price tag. Judge
tools on their merits.

• There are a lot of expensive project management tools. Are they worth it?

John:

Try not to think about how much a tool cost when you look at its output.

---

Picks

JP:

If you're an Apple fan boy/girl, you might be interested in what Steve Jobs had
to say about Object-Oriented Programming. This is an excerpt from a 1994 Rolling
Stone interview where Steve (not a programmer) explains OOP in simple terms.

Jeff Goodell: Would you explain, in simple terms, exactly what object-oriented
software is?

Steve Jobs: Objects are like people. They’re living, breathing things that have
knowledge inside them about how to do things and have memory inside them so they
can remember things. And rather than interacting with them at a very low level,
you interact with them at a very high level of abstraction, like we’re doing
right here.

Here’s an example: If I’m your laundry object, you can give me your dirty
clothes and send me a message that says, “Can you get my clothes laundered,
please.” I happen to know where the best laundry place in San Francisco is. And
I speak English, and I have dollars in my pockets. So I go out and hail a
taxicab and tell the driver to take me to this place in San Francisco. I go get
your clothes laundered, I jump back in the cab, I get back here. I give you your
clean clothes and say, “Here are your clean clothes.”

You have no idea how I did that. You have no knowledge of the laundry place.
Maybe you speak French, and you can’t even hail a taxi. You can’t pay for one,
you don’t have dollars in your pocket. Yet, I knew how to do all of that. And
you didn’t have to know any of it. All that complexity was hidden inside of me,
and we were able to interact at a very high level of abstraction. That’s what
objects are. They encapsulate complexity, and the interfaces to that complexity
are high level.

John: Time Timer - https://www.timetimer.com/ - Pomodoro - Physical Device