Are Rewrites always a Bad Idea?
summary
A legacy C++ item‑response service gets fully rewritten into Kotlin Spring Boot using the Kotlin standard library (rejecting multik and smile), splitting work into three deployable chunks, validating models with the original researcher via input/output test vectors, and replacing requests that once sent up to 60,000 lines of JSON per call; the new stateless service implements the revised mathematical model (logs, e and ln based calculations) and runs 100% in production after decommissioning the old app.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 2:14About Tri Fork
- 7:45Code Base
- 9:05Why Rewrite
- 11:54No Small Steps
- 22:22The Spike
- 29:47The Model
- 33:36The Example
- 36:26Multik
- 38:52Oilers Number
- 40:56C
- 49:07Conclusion
related talks
55mAre Rewrites always a Bad Idea?
51mRe-Architecting Applications (Without a Rewrite!)
27mBig Rewrite Strikes Again
32mLegacy Code: Big Rewrite or Progressive Rejuvenation?
40mGrowing Pains: Scaling and Re-architecting Apps Under Fire
15mReactifying your application
33mTaylor’s Guide to Big Rewrites
46mGet Reactive! Programming, Systems, and Microservices