Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Groundhog Day Development Method (HackConf ...

The Groundhog Day Development Method (HackConf 2019)

Bozhidar Batsov

October 12, 2019
Tweet

More Decks by Bozhidar Batsov

Other Decks in Programming

Transcript

  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.