Rocks
In a word, no. Regardless of what we may want to believe, software development is a reductive process, which means we first need to understand the problem, develop a solution to the problem, and then implement the solution. Making the process of understanding the problem visible is not an example of BUFD. Rather it is making the “….hardest part of developing a software system” visible and managed.
Crushers are Rocks, and as Rocks, they must be well formed.
The visibility into the analysis process created by Crushers also enables us to see if we falling into the BUFD trap.
Yes and no.
Yes, because both a spike and a crusher serve a similar purpose, which is to create the knowledge we need to make better decisions moving forward.
No, because a crusher is for learning about the problem space, while most of us associate a spike with learning how to implement a specific solution. This may sound like we are being a bit academic, but we have several justifications for simply not re-using the term spike:
- First, the term spike has a very strong meaning for software development teams, and expanding the definition may have come across as confusing. Our industry has a very bad habit of creating confusion by overloading well-known terms. Consider the challenges people have with terminology like Epics, and Capabilities.
- Second, the usual scope of a spike is maybe a day or two of investigative work, whereas a crusher may be close to the full duration of a sprint.
- Finally, the term Crusher fits nicely into the Rock Crusher model metaphor. The term was inspired by the additional ore processing steps in the mining industry, where heavy steel balls are added to the rock crushing process. Some mining processes also use what are call “rod mills” where instead of heavy balls, heavy rods are used to crush mineral bearing ore.
A Ball Mill for Crushing Mineral Bearing Ore