Have you ever started a project only to realize, halfway through, that it is much more complicated than what you originally thought and that it would take twice as long as you had originally planned? Even worse, it would also need collaboration from three different teams because it touches their codebase as well.
Software engineers across various organizations have run into this same issue many times. So, what’s the solution to this persistent thorn?
The process that may help you resolve this is usually called a “spike”, wherein the engineer(s) leading a project dive deep into figuring out the unknowns of a project before it begins. In this talk, I’ll go over what a spike is, how to successfully spike a project, and lessons that I’ve learned from leading several technically complex projects, across three different companies, and various different teams.
You will leave this talk with knowledge on:
- How to evaluate whether you need a spike or not
- How to come up with the right assumptions you could validate/invalidate before writing the tech spec
- How to determine the technical scope of a project (teams, services, key stakeholders) that needs to be involved
