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

More Decks by Bozhidar Batsov

Other Decks in Programming


  1. • 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”
  2. • 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)
  3. • 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
  4. • 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
  5. • Implemented in node.js • Solid test coverage • Pretty

    small codebase (around 5k) • Serious performance issues • Frequent crashes • It was deemed “unfixable”
  6. • 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
  7. The choice of a tech stack should be aligned with

    the people who are supposed to use it.
  8. • 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
  9. If you’re always chasing after the next hot technology then

    you’re never building something valuable.