Tracer bullets

05/11/18 • 29 min

iteration

Chapter 2 - A Pragmatic Approach

Overview = combine ideas and processes

duplicate knowledge throughout systems
don't split any one piece of knowledge across multiple system components (orthogonality)
insulate projects from their changing environments
gather requirements and implement code at the same time
how to give project estimates

This chapter is truly about a "pragmatic" approach to development

Tip 11: Don't Repeat Yourself

if you change one, you'll have to change another

Duplicated code arises differently:

imposed: devs feel they have no choice
inadvertent: devs don't realize they are duplicating
impatient: devs got lazy because it seems easier
interdeveloper: multiple people on a team duplicate a piece of info

we call these the "four i's"

"shortcuts make for long delays"
number 4 is a result of large teams - not having a --- dare I say --- a ubiquitous language
you need good communication to quell number 4
READ DOCS
Tip: Lean on code and programmatically generated things to prevent repeating yourself.

Tip 12: Make it easy to reuse

you want to create an environment where it's easier to find and reuse existing stuff so people don't have to go out and create their own
orthogonality
borrowed from geometry
two lines are orthogonal if they meet at right angles - think axes on a graph
move along (or parallel to the x-axis) and theres no change to the y-axis
in computing, "orthogonality" has come to mean independence / decoupling

TWO OR MORE THINGS are orthogonal if changes in one do not affect any of the others

i.e. database code will be orthogonal to the UI. you can change the interface without affecting the database

driving stick shift is not orthogonal
helicopter controls are not orthogonal

bottom line: non-orthogonal systems are hard to maintain

Tip 13: Eliminate Effects Between Unrelated things

design components that are self-contained. this is very much the case for react components.
and for ruby methods
and for js functions
you want: independent, single, well defined components
you want: single, independent components that don't need no man

You get two major benefits if you write orthogonal systems: increased productivity and reduced risk.

ways orthogonality can be applied to your work

teams can be more efficient if each major infrastructure component gets its own subteam: database, communications interface, middleware layer, etc
non orthogonal systems lead to bickering teams
system design: should be composed of a set of cooperating modules, each of which implements functionality independent of others
inherently, i think MVC is orthogonal
the flux pattern is also orthogonal in react applications. i think? ask yourself:

if i dramatically change the requirements behind a particular function, how many modules are affected?

Toolkits and Libraries

we're talking Ruby gems, Node modules, etc
choose technologies wisely

Testing

An orthogonally designed and implemented system is easier to test. Because the interactions between the system's components are formalized and limited, more of the system testing can be performed at the individual module level. This is good news, because module level (or unit) testing is considerably easier to specify and perform than integration testing.

building unit tests is a TEST of orthogonality.
easy unit tests == orthogonal

Reversability

Nothing is more dangerous than an idea if it's the only one you have.

Writing more orthogonal code allows you to more easily reverse changess or eb and flow with the needs of the project.

Bottom line: orthognality is about reduction of interdependency among system components

Tip 14: There are no final decisions

problem: critical decisions aren't easily reversable
imagine switching a codebase to use Mongo after having tens of thousands of records in a Postgres db
HOWEVER - if you REALLY abstracted the idea of a "database" out - you should have the flexibility to make that change, should you need to
you SHOULD prepare for contingencies

instead of carving decisions in stone, think of them mroe as being written in the sand at the beach. A big wave can come along and wipe them out at any time.

this is also why i love the Adapter pattern.
for example - making a folder called "Adapters" when making external http requests in a...

Chapter 2 - A Pragmatic Approach

Overview = combine ideas and processes

duplicate knowledge throughout systems
don't split any one piece of knowledge across multiple system components (orthogonality)
insulate projects from their changing environments
gather requirements and implement code at the same time
how to give project estimates

This chapter is truly about a "pragmatic" approach to development

Tip 11: Don't Repeat Yourself

if you change one, you'll have to change another

Duplicated code arises differently:

imposed: devs feel they have no choice
inadvertent: devs don't realize they are duplicating
impatient: devs got lazy because it seems easier
interdeveloper: multiple people on a team duplicate a piece of info

we call these the "four i's"

"shortcuts make for long delays"
number 4 is a result of large teams - not having a --- dare I say --- a ubiquitous language
you need good communication to quell number 4
READ DOCS
Tip: Lean on code and programmatically generated things to prevent repeating yourself.

Tip 12: Make it easy to reuse

you want to create an environment where it's easier to find and reuse existing stuff so people don't have to go out and create their own
orthogonality
borrowed from geometry
two lines are orthogonal if they meet at right angles - think axes on a graph
move along (or parallel to the x-axis) and theres no change to the y-axis
in computing, "orthogonality" has come to mean independence / decoupling

TWO OR MORE THINGS are orthogonal if changes in one do not affect any of the others

i.e. database code will be orthogonal to the UI. you can change the interface without affecting the database

driving stick shift is not orthogonal
helicopter controls are not orthogonal

bottom line: non-orthogonal systems are hard to maintain

Tip 13: Eliminate Effects Between Unrelated things

design components that are self-contained. this is very much the case for react components.
and for ruby methods
and for js functions
you want: independent, single, well defined components
you want: single, independent components that don't need no man

You get two major benefits if you write orthogonal systems: increased productivity and reduced risk.

ways orthogonality can be applied to your work

teams can be more efficient if each major infrastructure component gets its own subteam: database, communications interface, middleware layer, etc
non orthogonal systems lead to bickering teams
system design: should be composed of a set of cooperating modules, each of which implements functionality independent of others
inherently, i think MVC is orthogonal
the flux pattern is also orthogonal in react applications. i think? ask yourself:

if i dramatically change the requirements behind a particular function, how many modules are affected?

Toolkits and Libraries

we're talking Ruby gems, Node modules, etc
choose technologies wisely

Testing

building unit tests is a TEST of orthogonality.
easy unit tests == orthogonal

Reversability

Nothing is more dangerous than an idea if it's the only one you have.

Writing more orthogonal code allows you to more easily reverse changess or eb and flow with the needs of the project.

Bottom line: orthognality is about reduction of interdependency among system components

Tip 14: There are no final decisions

problem: critical decisions aren't easily reversable
imagine switching a codebase to use Mongo after having tens of thousands of records in a Postgres db
HOWEVER - if you REALLY abstracted the idea of a "database" out - you should have the flexibility to make that change, should you need to
you SHOULD prepare for contingencies

instead of carving decisions in stone, think of them mroe as being written in the sand at the beach. A big wave can come along and wipe them out at any time.

this is also why i love the Adapter pattern.
for example - making a folder called "Adapters" when making external http requests in a...

Previous Episode

NEW BOOK - The Pragmatic Programmer

The Pragmatic Programmer: From Journeyman to Master Preface (Chapter 1)

Welcome to Iteration: a weekly podcast about programing, development and design through the lens of amazing books, chapter-by-chapter

NEW BOOK Pragmatic Programmer

by Andy Hunt and Dave Thomas

This book will help you become a better programmer

this book was written in freaking 1999! I was 7.
programming is a craft
"as a programmer, you are part listener, part advisor, part interpreter, and part dictator. you try to capture elusive requirements and find a way of expressing them so that a mere machine can do them justice. you try to document your work so that others can understand it, and you try to engineer your work so that others can build on it. What's more, you try to do all this against the relentless ticking of the project clock. you work small miracle every day"
"you shouldn't be welded to any particular technology, but have a broad enough background and experience base to allow you to choose good solutions in particular situations"

What makes a pragmatic programmer

early adopter / fast adapter
inquisitive - you ask questions
critical thinker
realistic
jack of all trades

Tips

Tip 1: Care about your craft

"We who cut mere stones must always be envisioning cathedrals."

Tip 2: Think about your work - never run on auto pilot

"great lawns need small amounts of daily care, and so do great programmers."

"1% better every day. 365% bettere every year"

kaizen - continuous small improvements

Tip 3: Provide Options, Don't make lame excuses

basically, take responsibility
when something can't be done, explain what can be done to salvage the situation

Challenge

How do you react when someone - such as a bank teller, a mechanic, or a clerk - comes to you with a lame excuse. What do you think of them and their company as a result?

hmmmmm.... really gets you thinking

Tip 4: don't leave broken windows

Software entropy - aka Broken window theory - aka software rot

This is a great metaphor:

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment - ... so another window gets broken. People start littering. graffiti appears.

police in NY and other major cities have cracked (no put intended) down on small stuff in order to keep out the big stuff.
systems rot quickly with one broken window. wow. this cuts me deep. haha.
don't let entropy win!!!
in the opposite case, where there are no broken windows - and its extremely pristine - you don't want to be THAT guy that makes a mess.

Tip 5: Be a catalyst for change (gradual deception and you can get what you want haha)

"The three soldiers returning home from war were hungry. When they saw the village ahead their spirits lifted—they were sure the villagers would give them a meal. But when they got there, they found the doors locked and the windows closed. After many years of war, the villagers were short of food, and hoarded what they had. Undeterred, the soldiers boiled a pot of water and carefully placed three stones into it. The amazed villagers came out to watch. "This is stone soup," the soldiers explained.

"Is that all you put in it?" asked the villagers. "Absolutely—although some say it tastes even better with a few carrots...." A villager ran off, returning in no time with a basket of carrots from his hoard. A couple of minutes later, the villagers again asked "Is that it?" "Well," said the soldiers, "a couple of potatoes give it body." Off ran another villager."

Tip 6: Remember the big picture

(don't be the frog who gets boiled gradually)

Tip 7: Make quality a requirements issue

There will always be tradeoffs. When to ship?

Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution.

Challenges

look at some software you use. can you find evidence that companies are comfortable shipping software they know is not perfect. as a user, would you rather wait for them to iron out all of the bugs? have complex software and accept some bugs? opt for simpler software and have fewer defects?

Tip 8: Invest regularly in your knowledge portfolio

knowledge is an expiring asset
it becomes out of date as new techniques, languages, and environments are developed
JP's pick: https://www.youtube....

Next Episode

I'll get back to you...

Chapter 2 - A Pragmatic Approach

Tip 16: Prototype to learn

JP: I love doing this during "exploration" - careful not to use prototypes in prod 👀

John: prototype vs tracer bullet - Expectations: Remind them that you can build a great prototype of a new car out of balsa wood and duct tape, but you wouldn't try to drive it in rush-hour traffic! - Localhost with ngrok

Tip 17: Program Close to the problem domain

JP: Remember to focus on domain problems and not petty implementation details

John: Let your code be english! - Let it reflect the way your team talks. execute_email_delivery_protical vs send_email

Tip 18: Estimate to avoid surprises

JP: Be deliberate and keep track... wording is key (i.e. specificity)

John: Reality - scope is a Moving target - Tracer code and testing helps make sure estimates are well thought out. Charge to estimate / mockup.

Tip 19: Iterate the schedule with code

JP: Keep an open line of communication about expectations for scheduling

John: What to say when you are asked for an estimate "I'll get back to you" - Scope can be revised. Not just timeline.

Picks

JP: - Todoist
John: text expander - TextExpander lets you instantly insert snippets of text from a repository of emails, boilerplate and other content, as you type.