Strategic software development.

Introduction

This post covers how reconnaissance is vital to your product development toolkit.

Imagine you are a seasoned explorer.

You do enough research and planning to prevent significant obstacles from preventing your teams from reaching their goal. But you know you can’t predict what you’ll run into on the software development journey, so you prepare to be surprised.

When you hit a snag or need to figure out how to move forward, you know it makes little sense to keep building. Instead, you explore. Your team stops construction work to focus on finding good options.

Everyone on your team gathers intelligence through focused research to break through the roadblock, find a faster way to achieve your aim, or figure out if you’ve hit an impasse and need another way around.

Here’s the thing: There’s much more to software development than manufacturing. To be successful, tackle ambiguity. Plan for surprises.

Reconnaissance can help you understand if something is possible in your code base and how long it will take to implement it.

Perhaps there is an existing library or service that does exactly what you want but requires minor modifications to work in your current environment. Or maybe there’s no clear solution available, but someone else has tried something similar and shared their findings online.

Intelligence helps guide your development efforts while saving time (and thus money) by not having to come up with everything from scratch.

Research can also reveal if something is possible within your project’s scope by answering questions such as “Can I build this feature?” “How long would it take?” or “How much will it cost?”

What is a recon spike?

In a reconnaissance spike, your team stops construction work and switches gears for a sprint.

You stop the routine, day-to-day collaborative construction work. Every team member focuses on exploration with a single aim: to answer a single question or solve a specific problem.

Use reconnaissance to explore and answer questions your engineers can’t answer today. With a recon spike, the aim is research.

It’s best to switch your team’s regular code-slinging mindset because research is driven by intuition, insight, and exploration rather than following the typical production-focused construction work.

You’re now learning to solve something without tearing up your code base. The point is gathering intelligence, not coding.

Plan to scrap your research code, It should NEVER get into production. However, it provides a powerful reference guide.

After the recon work is done, you use what you’ve learned to plan a safer way to put any solutions you’ve found into production in the next sprint.

Research spikes are not a new idea in software engineering, but they are becoming more popular as companies try to bridge gaps in the best way possible.

Remember, research happens during software development, whether you make it explicit or not. The problem with recon code is that you need higher quality to go to production safely, while focused research requires testing options, moving fast, and breaking things.

So it’s better to differentiate, plan, and research safely.

By making research activities clear, your team will differentiate between writing code that is ready for production and doing exploratory work. One produces production-ready software, while the other produces intelligence.

How can I use recon spikes to improve my development process?

Recon spikes are an excellent way to get answers, validate ideas, and investigate new technologies.

• Before you commit, you can use them to investigate any new technology or library you’re considering using in your codebase.
• To test the performance of a particular database technology for your application.
• To investigate how well a new design pattern works as an alternative to what you currently use in your codebase (such as MVVM (Model-View-View-Model), COR (chain of responsibility,), IOC (inversion of control) frameworks, and more.)

How do you know when you’ve solved your problem with the reconnaissance spike?

As we have seen, the point of a research spike is not to build something. It’s research to test a theory and see whether you can achieve the goal you’ve been trying to reach in your existing codebase.

Even if your team does not achieve the goal, you will have learned a valuable lesson: how NOT to approach the problem. This intelligence means your team does not waste valuable time banging their heads against the wall.

And if you achieve a breakthrough, but only temporarily or under specific circumstances? Well, this is an opportunity for refactoring, optimization, and paying down technical debt!

But what about discovering a simple breakthrough? Then congratulations! You can safely close your research window. You now know enough to put your solution into action and switch to building work that is ready for production.

Who should I involve in a recon spike?

It depends on the gap.

Get the most out of your research spike and include all stakeholders involved in the roadblock.

Including:

• Customers
• Designers
• Product managers
• Technical writers (if they document or explain any parts of your codebase)
• Engineers
• Product owners

The nature of the obstacle you are tackling will help you know who you need.

For example, you need to talk to engineers and designers if you have a technical concern. For a design issue or opportunity, it’s best to involve your customer or product manager.

When should I schedule a recon spike in my development lifecycle?

Recon spikes are an excellent way to validate hypotheses and better understand your situation.

Use recon as a first step in exploring new technologies or when you want to:

• better understand your users and how they work
• learn how other people have solved the same problem in their codebase
• map the terrain of your current code base and find successful paths forward to achieve a technical aim

Use reconnaissance as part of your exploratory development process. While you’ll go down paths that may lead nowhere, you’ll gain valuable knowledge about the problem space. This way, you increase your chances of success and reduce the time, cost, and risks of making your next move.

How do I bring the knowledge from a recon spike into my team’s codebase?

It’s essential to remember that a research spike isn’t just exploration. It’s an opportunity to clarify the gaps. Not only that, but it’s a learning exercise for everyone involved.

For example, with technical reconnaissance, your team will have learned important things about the gap and the area affected by the changes that need to be made. Your whole team benefits.

It’s essential for your team to share what they’ve learned so that they can use these new ideas in their day-to-day production coding.

Making intelligent moves will improve your codebase’s conciseness, quality, and stability.

Research spikes are a valuable addition to your software development lifecycle.

Research spikes are a valuable addition to your software development lifecycle. They help you solve problems quickly, understand your situation better, and find the right solution.

• They are a great way to experiment with new ideas without wasting unnecessary time or money.
• It’s easy to get lost in research. The spike comes in handy when exploring options for solving technically challenging hurdles. It allows you to focus on one or two solutions at a time without getting distracted by other problems that aren’t relevant right away.
• Containing your research to time-boxed activities allows you to decide quickly and move forward with your project.

As you learn more about a situation, you can use more small recon spikes to guide your research in a particular direction.

Conclusion

Recon spikes are a great way to keep your code base healthy while learning to solve specific project challenges.

Recon spikes are an important part of any professional software development toolkit. They help you learn about and get around gaps quickly, before you burn too much time or effort.

Best wishes and warm regards—Matt

By the way…

Has your software discovery, design, and development process become more complicated than you’d like?

Producing quality products requires time, effort, and skill.

Spikes are a way to answer specific, unexpected, and critical questions. They are the best way to learn what you need to know to achieve your goal.

Are you ready to optimize your software development process?

Click here or contact us today.

Truth Shield is here for you. We aim to help you succeed in the software development world.