The Groundhog Day Development Method (HackConf 2019)

Transcript

2. Привет!
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. Божидар
23. @bbatsov
24. emacsredux.com
25. metaredux.com
26. #7 on the list of top white hackers in Bulgaria!
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
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!
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.
49. moneyforsomething.com
50. ETFmatic
52. The Main Event
53. The Groundhog Development Method
54. What the f*ck is a groundhog?
60. The Groundhog DAY Development Method
62. 8.0/10
63. Life has a funny way of repeating itself…
64. Software development has a funny way of repeating itself
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
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
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
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.
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
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
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!
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
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