Are Rewrites always a Bad Idea?
summary
A legacy C++ item response theory service with four endpoints and a stateless service pattern gets ported to Kotlin + Spring Boot using the Kotlin standard library (after small experiments with multic and smile), guided by an R model and test vectors from the researchers. The original required sending 60,000 lines of JSON per request and was a black box; the rewrite is delivered in three deployable chunks, validated against the researcher’s outputs, and replaces the old app 100% in production.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 1:48Rewrites justified
- 9:39Reasons to rewrite
- 12:09Small steps vs learning curves
- 15:17Skills mismatch
- 18:51Small scope deployable
- 22:03Strangler fig pattern
- 23:10Spikes validate ideas
- 25:15Project outcome
- 25:37Application audit
- 27:26Hidden legacy complexity
- 29:10Changing statistical models
- 30:37Collaborate with experts
- 31:40Kotlin and Spring Boot
- 33:27Numerical libraries
- 34:13Arrays vs objects
- 39:35Model math foundations
- 43:54Growth and leadership
- 47:07Documentation and team communication pitfalls
- 49:14Imposter syndrome
- 50:16Conclusion
related talks
15mMajor migrations made easy
45mMajor migrations made easy
48mLegacy, for lack of a better word, is good
42mSo You Want To Rewrite That...
34mPull Off the Split: Succeeding with OpenRewrite
38mRetrofit your Java App with a Reactive Flow Pipeline
50mThree Rewrites, One Startup - An Architect's Journey
51mResponsible Microservices