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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  5. Longest talk in the history of
    conferences!

    View full-size slide

  6. Third time is a charm!

    View full-size slide

  7. Божидар

    View full-size slide

  8. emacsredux.com

    View full-size slide

  9. metaredux.com

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  13. Expert in cyber security

    View full-size slide

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

    View full-size slide

  15. The Don Juan of IT in
    Bulgaria

    View full-size slide

  16. slide intentionally
    left blank

    View full-size slide

  17. Personal Finance
    in 3 minutes

    View full-size slide

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

    View full-size slide

  19. 53 billion BGN in bank
    deposits.

    View full-size slide

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

    View full-size slide

  21. Official annual inflation in
    Bulgaria:
    3%

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  25. moneyforsomething.com

    View full-size slide

  26. The Main Event

    View full-size slide

  27. The Groundhog
    Development Method

    View full-size slide

  28. What the f*ck is a
    groundhog?

    View full-size slide

  29. The Groundhog DAY
    Development Method

    View full-size slide

  30. Life has a funny way of
    repeating itself…

    View full-size slide

  31. Software development has a
    funny way of repeating itself

    View full-size slide

  32. From greenfield to legacy in 2
    years

    View full-size slide

  33. Case Studies

    View full-size slide

  34. A Study in Groundhogs

    View full-size slide

  35. Booking Engine

    View full-size slide

  36. • 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 full-size slide

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

    View full-size slide

  38. The (Rewrite) Wasteland

    View full-size slide

  39. Big Bang Rewrites Almost
    Always Fail

    View full-size slide

  40. • 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 full-size slide

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

    View full-size slide

  42. Compound Interest Rate

    View full-size slide

  43. Content
    Management
    System

    View full-size slide

  44. • 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 full-size slide

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

    View full-size slide

  46. Original estimate - 6 months

    View full-size slide

  47. 3 years later…

    View full-size slide

  48. • 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 full-size slide

  49. What’s the moral of the story?

    View full-size slide

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

    View full-size slide

  51. Sometimes WordPress is not a
    bad thing…

    View full-size slide

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

    View full-size slide

  53. Quote Streaming Service

    View full-size slide

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

    View full-size slide

  55. node.js is the problem

    View full-size slide

  56. Let’s rewrite this in Clojure!

    View full-size slide

  57. • 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 full-size slide

  58. Everything is fixable.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  61. 1,500,000 downloads

    View full-size slide

  62. • 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 full-size slide

  63. Flexible Extension
    Mechanism

    View full-size slide

  64. Simplicity is a design choice.

    View full-size slide

  65. 800,000 downloads

    View full-size slide

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

    View full-size slide

  67. Dependencies are the
    highway to hell

    View full-size slide

  68. Stability is a design choice.

    View full-size slide

  69. Hammock time

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  72. slide intentionally
    left blank

    View full-size slide

  73. Keep it simple

    View full-size slide

  74. Limit external dependencies.

    View full-size slide

  75. Be very cautious with adding
    new features.

    View full-size slide

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

    View full-size slide

  77. Breaking Changes!

    View full-size slide

  78. Don’t rewrite anything (big)!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  81. Incremental design

    View full-size slide

  82. Legacy is “complex”

    View full-size slide

  83. Micro-services are not a silver
    bullet

    View full-size slide

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

    View full-size slide

  85. Learn how to deal effectively
    with legacy code

    View full-size slide

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

    View full-size slide

  87. You have to get burned.

    View full-size slide

  88. There’s no substitute for
    experience.

    View full-size slide

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

    View full-size slide