Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Pragmatic Programming

Pragmatic Programming

The tensions between business & engineering and some thumb rules of how to be a pragmatic engineer.

Vishnu Gopal

June 14, 2020
Tweet

More Decks by Vishnu Gopal

Other Decks in Programming

Transcript

  1. Pragmatic Programming
    Vishnu Gopal

    View Slide

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

    View Slide

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

    View Slide

  4. The what & why of pragmatic.
    A personal definition.

    View Slide

  5. Business++
    Technology++
    Middle way = pragmatic.

    View Slide

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

    View Slide

  7. Business >> Technology

    View Slide

  8. Technology >> Business

    View Slide

  9. Pragmatic might be an answer to
    this conflict.

    View Slide

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

    View Slide

  11. Business & Technology should
    work hand-in-hand.

    View Slide

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

    View Slide

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

    View Slide

  14. 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”

    View Slide

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

    View Slide

  16. Prioritise change: One basic
    thumb rule to judge “pragmatic”

    View Slide

  17. View Slide

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

    View Slide

  19. When faced with two or more alternatives
    that deliver roughly the same value, take
    the path that makes future change easier.

    View Slide

  20. 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. …?

    View Slide

  21. Make future change easy.

    View Slide

  22. What are the current & future
    requirements?

    View Slide

  23. 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. ..?

    View Slide

  24. 1. How much money can I spend?
    2. When do I want it to be done?

    View Slide

  25. More art than science :)

    View Slide

  26. View Slide

  27. Innovation Points & NIH

    View Slide

  28. View Slide

  29. “You have a limited number of
    innovation points to spend”

    View Slide

  30. Big Rocks = things unique to your product.
    Small Pebbles = stuff that directly helps your
    business
    Sand = everything else.

    View Slide

  31. Big Rocks = your core product idea
    Small Pebbles = Slack, Email, Google
    Analytics, …
    Sand = glue that holds everything together.

    View Slide

  32. Big Rocks = closed-source “IP”
    Small Pebbles = outsource everything (open-
    source or paid)
    Sand = spend ~10-20% of your dev-budget.

    View Slide

  33. Optimize your development workflow
    so you spend >80% of your
    development time on the big rocks.

    View Slide

  34. 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).

    View Slide

  35. “Develop a voice over IP solution
    for mobile operators”

    View Slide

  36. What is the big rock here?

    View Slide

  37. Big rock = the crucial piece that
    delivers value to customers.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  41. Big rock != the most technically
    challenging piece.

    View Slide

  42. Big rock = the crucial piece that
    delivers value to customers.

    View Slide

  43. Measure what you want to
    improve

    View Slide

  44. Unless you measure, there is no
    way to quantify improvement.

    View Slide

  45. Lagging measure: directly
    measures your improvement.

    View Slide

  46. Leading measure: measures
    something that might/will influence
    what you want to measure.

    View Slide

  47. Revenue
    Lagging measure = cash in bank.
    Leading measure = number of new sales
    leads.

    View Slide

  48. Software Quality
    Lagging measure = number of bugs reported
    in production.
    Leading measure = coverage% for new code.

    View Slide

  49. Some good things to measure for
    pragmatic programming.

    View Slide

  50. 1. Customer satisfaction.
    NPS, qualitative surveys, …

    View Slide

  51. 2. Software Quality
    Code Coverage, bugs reported, …

    View Slide

  52. 3. Usage
    DAU/MAUs, engagement metrics,

    View Slide

  53. “Customers are reporting so
    many bugs in production!”

    View Slide

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

    View Slide

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

    View Slide

  56. So that is a small window into
    pragmatic programming.

    View Slide

  57. There was very little about
    programming in there

    View Slide

  58. Levelling up as a programmer =
    understanding nuances of
    business too

    View Slide

  59. But do read the book.
    “Rubber duck debugging”
    “Broken windows theory”

    View Slide

  60. Thank you
    Questions?

    View Slide