Slide 1
Slide 1 text
Pragmatic Programming
Vishnu Gopal
Slide 2
Slide 2 text
About Me
Programmer, loves to build products.
• Around ~15years experience programming.
• First job was at SlideShare
• Was part of & founded a few startups.
• Currently very interested in frontend stuff.
• Joined Doist 12th May.
• @vishnugopal on Twitter, Github
• vishnugopal.com
Slide 3
Slide 3 text
Topics
1. The what & why of pragmatic. A personal definition.
2. Prioritise change: One basic thumb rule to judge “pragmatic”
3. The Pragmatic Programmer book
4. Innovation Points & NIH syndrome
5. Measure what you want to improve
Slide 4
Slide 4 text
The what & why of pragmatic.
A personal definition.
Slide 5
Slide 5 text
Business++
Technology++
Middle way = pragmatic.
Slide 6
Slide 6 text
Business Technology
1. “Good for customer”
2. Brings in revenue
3. A feature that a
customer is asking for
4. Good for sales & sales
leads.
5. Convincing investors.
1. “Build good software”
2. Reduce tech debt
3. Improve architecture
4. Build team skills.
5. Contributes back to
open source.
Slide 7
Slide 7 text
Business >> Technology
Slide 8
Slide 8 text
Technology >> Business
Slide 9
Slide 9 text
Pragmatic might be an answer to
this conflict.
Slide 10
Slide 10 text
Business Technology
Pick “React” for fast
development.
Build a marketing landing
page using a static site
provider
Introduce Cypress for
integration testing
Quickly launch a feature
so that we can get
featured on Techcrunch
Allocate some work in a
sprint to fix bugs.
Make a specialised white-
labeled version of the
product just to make the
first sale
Slide 11
Slide 11 text
Business & Technology should
work hand-in-hand.
Slide 12
Slide 12 text
Business Technology
Understand technology
problems and fit them
into business buckets like
“budget”, “roadmap” and
“investor decks”
Understand business
problems and use the
right technology pieces
to solve them.
Slide 13
Slide 13 text
Business Technology
Understand technology
problems and fit them
into business buckets like
“budget”, “roadmap” and
“investor decks”
Understand business
problems and use the
right technology pieces
to solve them.
Pragmatic
Slide 14
Slide 14 text
Business Technology
Understand technology
problems and fit them
into business buckets like
“budget”, “roadmap” and
“investor decks”
Understand business
problems and use the
right technology pieces
to solve them.
Pragmatic:
“The Middle
Way”
Slide 15
Slide 15 text
Business Technology
Pragmatic:
“The Middle
Way”
1. Lifelong search.
2. More “art" that science.
3. It’s ok to zigzag as long as you recognise you are zigzagging & come
back to the middle way.
Slide 16
Slide 16 text
Prioritise change: One basic
thumb rule to judge “pragmatic”
Slide 17
Slide 17 text
No content
Slide 18
Slide 18 text
1. Find out where you are
2. Take a small step towards your goal
3. Adjust your understanding based
on what you learned
4. Repeat
Slide 19
Slide 19 text
When faced with two or more alternatives
that deliver roughly the same value, take
the path that makes future change easier.
Slide 20
Slide 20 text
Example: “My sales team wants to do A/B
testing for our landing pages”
1. Code-based static site provider: Jekyll
2. Build an in-house A/B testing solution
3. Switch to a fully-managed landing page provider
4. Find a library that implements A/B testing
5. …?
Slide 21
Slide 21 text
Make future change easy.
Slide 22
Slide 22 text
What are the current & future
requirements?
Slide 23
Slide 23 text
Example: “My sales team wants to do A/B
testing for our landing pages”
1. I want to track conversions.
2. I want pretty graphs
3. I want to do segment-based targeted pages
4. ..?
Slide 24
Slide 24 text
1. How much money can I spend?
2. When do I want it to be done?
Slide 25
Slide 25 text
More art than science :)
Slide 26
Slide 26 text
No content
Slide 27
Slide 27 text
Innovation Points & NIH
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
“You have a limited number of
innovation points to spend”
Slide 30
Slide 30 text
Big Rocks = things unique to your product.
Small Pebbles = stuff that directly helps your
business
Sand = everything else.
Slide 31
Slide 31 text
Big Rocks = your core product idea
Small Pebbles = Slack, Email, Google
Analytics, …
Sand = glue that holds everything together.
Slide 32
Slide 32 text
Big Rocks = closed-source “IP”
Small Pebbles = outsource everything (open-
source or paid)
Sand = spend ~10-20% of your dev-budget.
Slide 33
Slide 33 text
Optimize your development workflow
so you spend >80% of your
development time on the big rocks.
Slide 34
Slide 34 text
Utilize open source. Maybe it doesn’t do
exactly what you want, but if it does 80%,
and it’s not a big rock, use it as pebbles
(outsource) + sand (glue you write).
Slide 35
Slide 35 text
“Develop a voice over IP solution
for mobile operators”
Slide 36
Slide 36 text
What is the big rock here?
Slide 37
Slide 37 text
Big rock = the crucial piece that
delivers value to customers.
Slide 38
Slide 38 text
Pieces that connect to
mobile operator
The telephony and call
bridging logic
The business logic &
workflow around voice
interaction
GUI & backend CRM tools
to manage workflows
Slide 39
Slide 39 text
Pieces that connect to
mobile operator
The telephony and call
bridging logic
The business logic &
workflow around voice
interaction
GUI & backend CRM tools
to manage workflows
Slide 40
Slide 40 text
Pieces that connect to
mobile operator
The telephony and call
bridging logic
The business logic &
workflow around voice
interaction
GUI & backend CRM tools
to manage workflows
Commercial product from
a vendor for SIGTRAN
connectivity
Open source product
Asterisk for call bridging
In-house developed
framework
Mix of a Rails CRM library
+ glue code to pull in data
into a database.
Slide 41
Slide 41 text
Big rock != the most technically
challenging piece.
Slide 42
Slide 42 text
Big rock = the crucial piece that
delivers value to customers.
Slide 43
Slide 43 text
Measure what you want to
improve
Slide 44
Slide 44 text
Unless you measure, there is no
way to quantify improvement.
Slide 45
Slide 45 text
Lagging measure: directly
measures your improvement.
Slide 46
Slide 46 text
Leading measure: measures
something that might/will influence
what you want to measure.
Slide 47
Slide 47 text
Revenue
Lagging measure = cash in bank.
Leading measure = number of new sales
leads.
Slide 48
Slide 48 text
Software Quality
Lagging measure = number of bugs reported
in production.
Leading measure = coverage% for new code.
Slide 49
Slide 49 text
Some good things to measure for
pragmatic programming.
Slide 50
Slide 50 text
1. Customer satisfaction.
NPS, qualitative surveys, …
Slide 51
Slide 51 text
2. Software Quality
Code Coverage, bugs reported, …
Slide 52
Slide 52 text
3. Usage
DAU/MAUs, engagement metrics,
…
Slide 53
Slide 53 text
“Customers are reporting so
many bugs in production!”
Slide 54
Slide 54 text
Build lagging measures to see the reality of the situation
1. Bugs by customer
2. Severity of bugs
3. Bugs effort estimate
4. Sprint metrics
Slide 55
Slide 55 text
Build leading measures to track influence & change
1. Code coverage for existing code
2. Code coverage for new code
3. Feature coverage for user workflows
4. Defect Escape Rate
Slide 56
Slide 56 text
So that is a small window into
pragmatic programming.
Slide 57
Slide 57 text
There was very little about
programming in there
Slide 58
Slide 58 text
Levelling up as a programmer =
understanding nuances of
business too
Slide 59
Slide 59 text
But do read the book.
“Rubber duck debugging”
“Broken windows theory”
Slide 60
Slide 60 text
Thank you
Questions?