Avoiding the pitfalls of rebuilding software
summary
Argues for concrete signals before rebuilding: define service level objectives and measure parity, track cycle time, bug counts, deployment frequency and MTTR, and use distributed tracing and observability (Honeycomb.io cited) to map ripple effects. Rebuild decisions hinge on decoupling domains, versioned APIs and whether partial refactor contains change, not on new shiny tech; examples include Kubernetes tradeoffs, legacy COBOL constraints and an Elixir/Phoenix migration case, with CircleCI.com as a CI example for pipelines.
AI-written summary · about
chapters (24)
- 0:00Introduction
- 1:15Guest introductions
- 6:49Guiding policies
- 13:56Architectures imperious
- 17:21Avoiding the pitfalls
- 20:03When do you spin them up
- 21:19Force multipliers
- 22:22Management change
- 22:54Where to start
- 23:54Scale of the rebuild
- 24:45Bring in engineering teams
- 25:18Who are the actors
- 27:41Accountability
- 28:07Quantitative metrics
- 30:22Deployment frequency
- 30:42Starting with you
- 32:22Potential incidents
- 32:53Mean time to repair
- 34:11How API design helps
- 36:16Why APIs are important
- 37:56Shiny Nude Tool Syndrome
- 38:51Craig Elisa Criteria
- 42:36People over politics
- 43:02Wrap up
related talks
28mAvoid overengineering & big ball of mud- 7 lessons for maintaining the balance
50mTactics and strategies on software development: how to reach ...
45mChanging attitudes toward legacy code
45mThe Goldilocks Problem of Software Delivery
43mThinking Architecturally
25mCommon platform team mistakes and how to avoid them
22mLeading software teams with context (visibility)
26mBe Awesome By Being Boring