The Groundhog Day Development Method (HackConf 2019)

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