The Groundhog Day Development Method (HackConf 2019)

The Groundhog Day Development Method (HackConf 2019)

1be785d1d788b82929e55fc83a9f0aaa?s=128

Bozhidar Batsov

October 12, 2019
Tweet

Transcript

  1. None
  2. Привет!

  3. None
  4. None
  5. None
  6. None
  7. None
  8. None
  9. The Books that Every Programmer Must Read (2015)

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

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

  12. Longest talk in the history of conferences!

  13. Third time is a charm!

  14. Божидар

  15. None
  16. None
  17. None
  18. None
  19. None
  20. None
  21. None
  22. None
  23. @bbatsov

  24. emacsredux.com

  25. metaredux.com

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

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

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

  30. Expert in cyber security

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

    Ruby
  32. The Don Juan of IT in Bulgaria

  33. None
  34. slide intentionally left blank

  35. Bonus talk

  36. Personal Finance in 3 minutes

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

    thought.
  38. 53 billion BGN in bank deposits.

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

  40. Official annual inflation in Bulgaria: 3%

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

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

    fund
  44. S&P 500

  45. The average annualized total return for the S&P 500 over

    the past 90 years is 9.8 percent.
  46. None
  47. None
  48. None
  49. moneyforsomething.com

  50. ETFmatic

  51. None
  52. The Main Event

  53. The Groundhog Development Method

  54. What the f*ck is a groundhog?

  55. None
  56. None
  57. None
  58. None
  59. None
  60. The Groundhog DAY Development Method

  61. None
  62. 8.0/10

  63. Life has a funny way of repeating itself…

  64. Software development has a funny way of repeating itself

  65. None
  66. From greenfield to legacy in 2 years

  67. Case Studies

  68. A Study in Groundhogs

  69. Booking Engine

  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”
  71. Let’s rewrite it in Java and that would fix all

    the problems!
  72. The (Rewrite) Wasteland

  73. Big Bang Rewrites Almost Always Fail

  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)
  75. Small improvements over a long period of time really add

    up!
  76. Compound Interest Rate

  77. None
  78. Content Management System

  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
  80. Let’s extract the CMS into a separate application!

  81. Original estimate - 6 months

  82. 3 years later…

  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
  84. None
  85. What’s the moral of the story?

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

    highly speculative.
  87. Sometimes WordPress is not a bad thing…

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

  89. Quote Streaming Service

  90. • Implemented in node.js • Solid test coverage • Pretty

    small codebase (around 5k) • Serious performance issues • Frequent crashes • It was deemed “unfixable”
  91. node.js is the problem

  92. Let’s rewrite this in Clojure!

  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
  94. None
  95. Everything is fixable.

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

    it.
  97. The choice of a tech stack should be aligned with

    the people who are supposed to use it.
  98. None
  99. RuboCop

  100. 1,500,000 downloads

  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
  102. Flexible Extension Mechanism

  103. Simplicity is a design choice.

  104. nREPL

  105. 800,000 downloads

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

    mechanism
  107. None
  108. Dependencies are the highway to hell

  109. Stability is a design choice.

  110. Hammock time

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

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

  113. slide intentionally left blank

  114. None
  115. None
  116. Keep it simple

  117. Limit external dependencies.

  118. Be very cautious with adding new features.

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

  120. Breaking Changes!

  121. None
  122. Don’t rewrite anything (big)!

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

  124. If you’re always chasing after the next hot technology then

    you’re never building something valuable.
  125. Incremental design

  126. Design

  127. Legacy is “complex”

  128. Micro-services are not a silver bullet

  129. I used to have one big problem, now I have

    many micro problems.
  130. Learn how to deal effectively with legacy code

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

  134. You have to get burned.

  135. There’s no substitute for experience.

  136. Felina

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

    Bulgaria 12.10.2019