An architecture spike in agile methodologies usually implies a software development method, which originates in the extreme programming offshoot of agile. It boils down to determining how much effort is needed to solve a particular problem or discover a workaround for an existing software issue.

So, let us explore the benefits and see how these spikes can help in improving quality and making testing easier—by shifting our attention to the left—challenging the specification at a very early phase, asking questions, and getting the ground ready for sensible software architecture, which will, in turn, improve the testability of our application under test.

More Details About Spikes

There are many benefits of spiking—to get to know the unknown unknowns, discover risks, reduce complexity, and provide proof for proving or disapproving a theory. Taking a deep dive into the idea behind the solution can help us better understand the potential architectural solutions and the likelihood of whether it will work.

A spike is not there to provide a finished working product or even an MVP. Its purpose is mainly to test a theory, so even though this concept is used (in the long run) to produce working software, the code written for spikes is often discarded after it has served its purpose. Spiking is usually done by ignoring architecture styles (which might seem odd at first as it can help discover the right architectural approaches for the system we are building), coding styles, design patterns, and general clean coding practices in favor of speed. Even though the spike may not directly produce software that will be delivered to the customer, in the long run, it still helps us ship better code in the end.

Spiking is a good tool for handling risks by discovering unknown risks and provides a great way to learn and reduce complexity. A very common approach is to come up with spikes around a theory and follow the code with a small number of tests. Even though the spikes are seen as discardable code, we don’t just throw them aside. While they don’t end up in the actual code that gets delivered, they provide insights and can serve as documentation to show how a solution was reached.

A Simple Example 

Let us assume that we have a new feature we need to develop, so we need to allow the users to be able to save a photo in their profile. To do that, a developer can make a spike where the following could be done:

• Have the JavaScript on the frontend communicate with the database:
  • Set up a database server locally.
  • Set up Node.js (or another server).
  • Use ODBC (Open Database Connectivity) API to connect to the DB.
• Test the spike:
  • Run a few sample queries.
  • Test the CRUD functionality.

What is mentioned in this simple example is all we need for a spike; it does not require any detailed documentation. The developer working on a spike will need to do some Googling, run a few commands from the terminal, and write a few lines of code for each theory. The spike would provide a possible direction for solving the challenge at hand; it can also include links for resources used, installs scripts, and the produced code to be used as a blueprint. Trying things out is way more beneficial than simply their sizing about them. The team was able to reduce the risk related to this feature—in this example, especially from the technical integrations side and even discovered new risks, such as accessing the DB using local JS!

How Does This Impact Testing?

Allowing us to explore spikes helps us identify the unknown unknowns, so, in a sense, spikes are a tool for early testing (used often when shifting testing to the left). By getting answers to what works and what will not work, we avoid many potential issues and delays by probing the requirements to distill them further. In turn, there are fewer bugs to report, fix, verify, and keep track of. Also, the earlier the testing is done; the more economical and fast it will be.

Can QA Use Spikes?

There is no real reason why not to. I have seen testers use spikes to try out and experiment with different approaches to automating some parts of the system under tests to determine the best approach. An architecture spike can help us try out different testing tools, such as new frameworks and libraries, and give us a first-hand experience of how a tool would behave without a system (when we try to automate some business rule, for example). Spikes are generally regarded as technical tasks (different than user stories), usually under an epic that is in the early development stages.

Conclusion

Spikes in agile are one of the tools that allow us to do what agile is intended to do in the first place: short, quick feedback cycles give us answers early in the development process. We focus on doing and trying instead of long, overly detailed planning. That is not to say that code architecture does not matter in agile (as we know, in waterfall architecture, it is very important and usually done in the design phase). In agile, we use a different approach. Agile practices, such as spikes, allow us to get an idea about architectural solutions that may work and info about the ones that may not work.

Software produced in the above-mentioned manner helps us reduce risk in our user stories and enabled the team to discover the right solutions using collaboration, constructive discussion, frequent experimentation, and compromise. In an informal sense, a lot of people happen to be using spikes without even realizing it! As long as you are trying to identify the unknown unknowns, have short feedback cycles, and try to determine technical and functional risks, you are doing agile. Spikes will help us in situations where we are not certain about the requirements and if there are a lot of unknowns and answers that need answers.