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

The Groundhog Day Development Method (HackConf 2019)

The Groundhog Day Development Method (HackConf 2019)

Bozhidar Batsov

October 12, 2019
Tweet

More Decks by Bozhidar Batsov

Other Decks in Programming

Transcript

  1. View Slide

  2. Привет!

    View Slide

  3. View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. View Slide

  9. The Books that Every
    Programmer Must Read
    (2015)

    View Slide

  10. The blog post I still have to
    write :-)

    View Slide

  11. Teach Yourself Programming in
    10+ years
    (2016)

    View Slide

  12. Longest talk in the history of
    conferences!

    View Slide

  13. Third time is a charm!

    View Slide

  14. Божидар

    View Slide

  15. View Slide

  16. View Slide

  17. View Slide

  18. View Slide

  19. View Slide

  20. View Slide

  21. View Slide

  22. View Slide

  23. @bbatsov

    View Slide

  24. emacsredux.com

    View Slide

  25. metaredux.com

    View Slide

  26. #7 on the list of top white
    hackers in Bulgaria!

    View Slide

  27. View Slide

  28. Божидар Батсов

    View Slide

  29. стацковарфлоу

    View Slide

  30. Expert in cyber security

    View Slide

  31. Expert in the following
    programming languages:
    Unix, Emacs, Perl and Ruby

    View Slide

  32. The Don Juan of IT in
    Bulgaria

    View Slide

  33. View Slide

  34. slide intentionally
    left blank

    View Slide

  35. Bonus talk

    View Slide

  36. Personal Finance
    in 3 minutes

    View Slide

  37. Disclaimer:
    That’s not an investment advice.
    Just some food for thought.

    View Slide

  38. 53 billion BGN in bank
    deposits.

    View Slide

  39. Current interest rate on
    deposits is around 0%.

    View Slide

  40. Official annual inflation in
    Bulgaria:
    3%

    View Slide

  41. Real annual inflation in Bulgaria:
    Don’t ask!

    View Slide

  42. View Slide

  43. Invest some of your savings in a
    low-cost mutual index fund

    View Slide

  44. S&P 500

    View Slide

  45. The average annualized
    total return for the S&P 500 over
    the past 90 years is 9.8 percent.

    View Slide

  46. View Slide

  47. View Slide

  48. View Slide

  49. moneyforsomething.com

    View Slide

  50. ETFmatic

    View Slide

  51. View Slide

  52. The Main Event

    View Slide

  53. The Groundhog
    Development Method

    View Slide

  54. What the f*ck is a
    groundhog?

    View Slide

  55. View Slide

  56. View Slide

  57. View Slide

  58. View Slide

  59. View Slide

  60. The Groundhog DAY
    Development Method

    View Slide

  61. View Slide

  62. 8.0/10

    View Slide

  63. Life has a funny way of
    repeating itself…

    View Slide

  64. Software development has a
    funny way of repeating itself

    View Slide

  65. View Slide

  66. From greenfield to legacy in 2
    years

    View Slide

  67. Case Studies

    View Slide

  68. A Study in Groundhogs

    View Slide

  69. Booking Engine

    View Slide

  70. • 15 year old codebase
    • A “magnificent” monolith
    • 500,000+ lines of C++ code
    • No automated tests
    • Pretty poor design
    • make clean install was taking 20-30 minutes
    • all the classes were prefixed with “Lin”

    View Slide

  71. Let’s rewrite it in Java and
    that would fix all the problems!

    View Slide

  72. The (Rewrite) Wasteland

    View Slide

  73. Big Bang Rewrites Almost
    Always Fail

    View Slide

  74. • Stabilize the existing system
    • Try to isolate some bounded contexts in it (e.g. billing, client-facing
    functionality, internal functionality)
    • Start extracting those components one by one (rewriting them if this
    seems highly beneficial)

    View Slide

  75. Small improvements over a long
    period of time really add up!

    View Slide

  76. Compound Interest Rate

    View Slide

  77. View Slide

  78. Content
    Management
    System

    View Slide

  79. • part of a huge multi-purpose Rails monolith (1,5 million lines of code)
    • the inability to quickly iterate on the CMS functionality impacted
    directly the revenue of the business
    • the CMS functionality was relatively simple

    View Slide

  80. Let’s extract the CMS into a
    separate application!

    View Slide

  81. Original estimate - 6 months

    View Slide

  82. 3 years later…

    View Slide

  83. • the extraction was mostly done, but still not quite
    • the new project was already considered legacy itself
    • internal conflicts within the team introduced a node.js rendering
    layer on top of the original CMS app, as some FE devs “disliked” Rails
    • the development process was still much slower than the goal we set
    out to achieve

    View Slide

  84. View Slide

  85. What’s the moral of the story?

    View Slide

  86. Any estimate with a 3+ months
    of a horizon is
    highly speculative.

    View Slide

  87. Sometimes WordPress is not a
    bad thing…

    View Slide

  88. Don’t become victims of the
    “Not Invented Here” syndrome

    View Slide

  89. Quote Streaming Service

    View Slide

  90. • Implemented in node.js
    • Solid test coverage
    • Pretty small codebase (around 5k)
    • Serious performance issues
    • Frequent crashes
    • It was deemed “unfixable”

    View Slide

  91. node.js is the problem

    View Slide

  92. Let’s rewrite this in Clojure!

    View Slide

  93. • we’ve encountered serious issues in an upstream Clojure library
    • there was a lot of internal opposition in the company towards the
    new service because supposedly “Clojure was too weird”
    • eventually we rewrote the service back to node.js
    • no performance issues
    • no crashes

    View Slide

  94. View Slide

  95. Everything is fixable.

    View Slide

  96. A tool is only as good as the
    person wielding it.

    View Slide

  97. The choice of a tech stack should
    be aligned with the people who
    are supposed to use it.

    View Slide

  98. View Slide

  99. RuboCop

    View Slide

  100. 1,500,000 downloads

    View Slide

  101. • features that add a lot of complexity get rejected
    • features that are not aligned with the core goals of the project get
    rejected
    • supporting obscure practices get rejected
    • inclusion of extra runtime dependencies happen extremely rarely
    • remove features

    View Slide

  102. Flexible Extension
    Mechanism

    View Slide

  103. Simplicity is a design choice.

    View Slide

  104. nREPL

    View Slide

  105. 800,000 downloads

    View Slide

  106. •no runtime dependencies
    •almost no breaking changes
    •super flexible extension mechanism

    View Slide

  107. View Slide

  108. Dependencies are the
    highway to hell

    View Slide

  109. Stability is a design choice.

    View Slide

  110. Hammock time

    View Slide

  111. Hammock-driven
    Development
    https://www.youtube.com/watch?v=f84n5oFoZBc

    View Slide

  112. Different design approaches for
    libraries/tools and applications.

    View Slide

  113. slide intentionally
    left blank

    View Slide

  114. View Slide

  115. View Slide

  116. Keep it simple

    View Slide

  117. Limit external dependencies.

    View Slide

  118. Be very cautious with adding
    new features.

    View Slide

  119. Remove features that are
    rarely used/didn’t work out.

    View Slide

  120. Breaking Changes!

    View Slide

  121. View Slide

  122. Don’t rewrite anything (big)!

    View Slide

  123. Say “No!” to
    hype-driven development

    View Slide

  124. If you’re always chasing after the
    next hot technology then you’re
    never building something valuable.

    View Slide

  125. Incremental design

    View Slide

  126. Design

    View Slide

  127. Legacy is “complex”

    View Slide

  128. Micro-services are not a silver
    bullet

    View Slide

  129. I used to have one big problem,
    now I have many micro
    problems.

    View Slide

  130. Learn how to deal effectively
    with legacy code

    View Slide

  131. View Slide

  132. View Slide

  133. What’s the best way to learn
    that fire burns?

    View Slide

  134. You have to get burned.

    View Slide

  135. There’s no substitute for
    experience.

    View Slide

  136. Felina

    View Slide

  137. Credits
    twitter: @bbatsov
    github: @bbatsov
    https://metaredux.com
    https://emacsredux.com
    HackConf 2019
    Sofia,
    Bulgaria
    12.10.2019

    View Slide