Pragmatic Programming

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

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