How to effectively "Spike" a complex technical project
summary
Advocates a concrete ritual: create a project-playground branch, let CI fail, treat code as throwaway and avoid tests, and limit the spike to one or two weeks; enumerate new vs modified surfaces, tag risky code paths with annotations in Java or Kotlin, and dump findings into a minimal spec listing what to discuss and which teams to involve. The goal is to expose unknowns quickly and decide whether a project is feasible before committing months of work.
AI-written summary · about
chapters (7)
- 0:00Introduction
- 1:03Project timelines and expectations
- 2:56Extreme approaches to projects
- 4:01What is a technical spike
- 5:43Spikes gone wrong
- 6:49Conducting a technical spike
- 9:38Final thoughts
related talks
29mDriving clarity in ambiguous projects
43mThinking Architecturally
55mGetting Unstuck Strategies for Surviving in a Rapidly Changing Post-Agile World
51mHacking Your Processes
39mManaging Complexity: Best Practices for Software Development Project Manager
01h 06mDecisions, Decisions — Dan North on Trade-offs in Software
51mCommon pitfalls in engineering teams and how to avoid them
41mWhy Promising Nothing Delivers More and Planing Always Fails