Wayfinding in Engineering: Communicating the Process
Explaining the software development process is often tricky, especially when talking to non-technical stakeholders. A common misconception is that the process is very linear. An engineer clearly defines the project specifications and then methodically types the solution from start to finish. This mental model could be applied to putting together a piece of Ikea furniture, following the steps to deliver the expected outcome.
Engineering software is less following a clear route and more like wayfinding through unknown territory with a trusty compass and some knowledge of the landmarks. We often say things like "Red-Green-Refactor" or:
"Make it work, make it right, make it fast."
— Kent Beck
In this post I'll discuss why wayfinding (prototyping, testing, exploring, and iterating) is an essential part of the software development life cycle and why providing for and communicating these steps to stakeholders is challenging yet necessary.
Engineering as Wayfinding
Wayfinding is the process of determining and following a path between an origin and a destination. Traditionally, one might not necessarily know the exact route ahead of time. You may have a general direction and landmarks to guide you, making decisions as obstacles are encountered or new information is discovered.
Engineering great software requires a similar pattern:
- Define a Starting Point: Begin with a problem statement or product requirement.
- Visualize the Deliverable: Have a general understanding of what success looks like. Ideally, this is clearly measurable.
- Exploration: The path between these points is rarely linear, involving exploration, dead ends, deleted code, and discovery.
Engineering can be defined as the practice of applying scientific principles, mathematics, and creative thinking to design, build, and test systems, structures, and processes to solve problems and address human needs.
Engineers don't simply code; they design. They test hypotheses, evaluate feedback, and adjust their approach based on what they learn along the way. This can often mean rewriting some or all of a codebase and changing the approach based on learnings. Communicating the need for rewrites and, more importantly, the impact of the effort is frequently a sticking point.
The Power of Prototyping
Prototyping is one of the most powerful tools in an engineer's toolkit. It allows teams to explore possibilities and test assumptions quickly with minimal investment. A prototype enables engineers to quickly test a concept, gather feedback, and make informed decisions without the commitment of production-ready code.
By definition, a prototype is not a finished product. It is a means of learning and gathering information. It can also be a mode of wayfinding, exploring technical solutions, and testing their efficacy. To maximize creativity and experimentation in the prototyping process, trashing the prototype and starting fresh must be an allowed or even desired outcome.
On Rewrites - Good vs Risky
When we rewrite code, it's not necessarily because our first attempt failed. Instead, it's part of the natural learning process in software development. As we build, we discover new information that changes our understanding of the problem or solution.
Engineers rewrite code for many pragmatic reasons:
- Finding a more elegant or efficient algorithm that improves performance
- Discovering that a chosen design pattern breaks down at scale
- Realizing there's a better architectural approach for long-term maintenance
- Learning through user feedback that our assumptions about interaction patterns were incorrect
These rewrites can be valuable steps forward, not wasted effort. The initial version of code often serves as a learning tool that informs a more refined solution. Experienced engineers are comfortable discarding code. They understand that the knowledge gained is often more valuable than the code itself.
In an environment of rapid iteration, reworking and rewriting code can be highly effective as new needs are discovered and efficiencies are found. However, there is a tendency in engineering to always want to start over and rewrite in the latest framework or language or rewrite because of a lack of understanding of the original code. Large-scale rewrites of established systems are highly risky. It is unlikely that years of learning, testing, and uncovering edge cases will be correctly addressed in the first pass of a large-scale rewrite. More likely, the rewrite project will have many regressions, go over schedule and/or budget, and result in tech debt when corners are cut to get the project to completion.
Instead, I would recommend addressing large areas of tech debt in pieces, tackling them when the business needs align with the work and updates are required in that area. Build in time to refactor problematic code but limit the scope to the needs of the project at hand, with clearly defined outcomes and measures of success. The Strangler Fig Pattern [1] [2] can also be a sound approach that allows for new work and iteration while eliminating older sections of code.
The Communication Challenge
While the value of wayfinding and iteration in software engineering may seem evident to its practitioners, getting buy-in from key stakeholders is not always easy. Let's explore why it's difficult to get alignment on providing for wayfinding and the resulting rewrites.
The Finished Product Fallacy
Most people only interact with completed software products. They never see the messy process of creation and refinement. This leads to the "Finished Product Fallacy". The assumption that software emerges in its final state, much like manufactured goods coming off an assembly line.
The Linear Planning Expectation
Traditional project management enforces linear thinking: define requirements, design solutions, implement, test, and deploy. This waterfall mentality creates the expectation that software development should follow a predictable, sequential path when, in reality, it's highly iterative.
The Invisible Nature of Software Work
Unlike visual design or UI development, where progress is immediately apparent—where mockups evolve, and interfaces take shape on screen—software engineering happens mainly beneath the surface. The work occurs in codebases and systems architecture that remain invisible to the end user and most stakeholders. This inherent invisibility makes it challenging for product managers, executives, and other non-technical team members to perceive the exploratory nature of backend development or appreciate the critical learning that happens with each iteration.
Strategies for Effective Communication
Despite these challenges, we can build better understanding with our non-technical colleagues.
Use the Right Metaphors
Abandon misleading metaphors like construction or manufacturing. Instead, use analogies that better capture the exploratory nature of software development:
- Scientific Research: Scientists form hypotheses, test them, and refine their understanding.
- Creative Writing: Authors draft, revise, and sometimes wholly rewrite sections of their work.
- Product Design: Designers create prototypes, test with users, and iterate based on feedback.
Make the Process Visible
Create visibility into the development process:
- Share early prototypes, even if they're rough
- Demonstrate how code evolves through iterations
- Celebrate learning moments, not just feature completions
- Use visualization tools to make progress tangible
Educate on Value Creation
Help stakeholders understand that value in software development isn't created linearly:
- Early iterations may produce little visible progress but generate critical insights
- "Failed" approaches often contribute significantly to successful solutions
- The fastest route to a reasonable solution often involves exploring multiple paths
Frame Rewriting Positively
When communicating about code changes and rewrites, language matters. Instead of using terms like "rework" or "fixing mistakes," try positioning the work in terms of evolution and growth:
- "Based on what we've learned from real users, we're improving the software design."
- "Now that we've seen how the system performs in production, we can optimize key areas."
- "Our initial implementation helped us understand the problem space better. We can now build a more scalable solution."
This isn't just semantics. It's an accurate reflection of the iterative nature of quality software development.
Embracing Uncertainty
At its core, engineering is about navigating uncertainty. When we acknowledge this reality, we can create more realistic expectations and healthier team dynamics.
Building Discovery Time Into Estimates
Explicitly account for exploration and learning in your project timelines. Rather than treating discovery as an afterthought, recognize it as a necessary part of the process.
Creating Safe Spaces for Iteration
Foster a culture where testing hypotheses and revising approaches are celebrated rather than penalized. Teams that feel safe to explore often find more creative, innovative, and effective solutions.
Measuring Progress Differently
Instead of measuring progress solely by feature completion, incorporate metrics that value learning:
- Knowledge gained about user needs
- Technical obstacles identified and addressed
- Approaches tested and evaluated
- Risk reduction through exploration
Conclusion
Engineering is wayfinding. We navigate from problem to solution through a process of exploration, testing, and iteration. By embracing this reality and effectively communicating with non-technical stakeholders, we create the space to foster creativity and build high-quality software.
The next time someone asks why you need to rewrite code that "already works," remember that you're not merely building. You're navigating! The path to exceptional software is rarely straight. That's not a bug; it's a feature of the creative problem-solving process that makes engineering so challenging and rewarding.
Embrace the journey of wayfinding. Communicate its value clearly, and you'll find more understanding and support for the iterative nature of engineering excellence.
"I have not failed. I've just found 10,000 ways that won't work."
— Thomas Edison