Journey Development vs. Destination Development: Choosing the Right Path for Software Projects
Posted on July 25, 2023 (Last modified on July 26, 2023 )
6 minutes • 1102 words
For me, embarking on a software development journey can take two distinct paths - the Journey Development Path and the Destination Development Path. Each approach brings its unique set of goals, challenges, and rewards. In this blog post, we will explore the key differences between these two development philosophies and discuss how they influence us as developers. By the end of this article, my hope is that you will understand the differences between these two approaches and have some insight on when and why I think you should choose a specific path.
Journey Development: Embracing Learning and Exploration
In the Journey Development Path, the primary focus is on learning, experimentation, and exploring new technologies, ideas, or domains. The ultimate goal is not necessarily to ship a complete solution but to gain knowledge and insights along the way. Key points include:
- Success through Learning: Even if the project is not completed, Journey Development considers it a success if valuable lessons are learned during the process.
- Solid Domain Understanding: To fully embrace the journey, we must have a strong grasp of the domain, allowing them to divert cognitive load towards exploring new technology.
- The Role of the Explorer: In this role, we become scientists or academics, seeking to expand their knowledge and skillset.
You may want to choose the Journey Development Path when learning something new is your goal. It's okay to not ship a finished product, but you should be able to learn something in the process. Perhaps that's how to deploy an application on Kubernetes, the way that Rust's lifetimes works, or how to integrate with the hot new API that everyone is talking about (cough cough ChatGPT).
Journey Development proves most beneficial in certain scenarios, particularly when working on personal projects, experimental prototypes, or when the primary objective is to expand one's skillset rather than delivering a commercial product. In these cases, success is defined not solely by shipping a solution but by the learning and growth that occur along the way.
This approach is often favored in research or educational settings, where exploration and experimentation are encouraged. However, it's important to consider the context and support available, as Journey Development may require more time and resources compared to Destination Development.
Example: Using Kubernetes for a Task List Application
Developers familiar with the concept of task lists might explore Kubernetes to deploy a simple Task List application. Though Kubernetes might be overkill for such a straightforward application, it provides an opportunity to focus on learning and experimenting with the technology.
Destination Development: Focused on Shipping Solutions and Customer Success
The Destination Development Path, on the other hand, centers around shipping a viable solution and achieving success when customers start using the product. Key points include:
- Success upon Shipping: The primary measure of success in Destination Development is delivering a complete, functional solution to end-users.
- Utilizing Familiar Technology: we choose tools and technologies they are already proficient in, reducing the learning curve and allowing more attention on building the final product.
- The Role of the Entrepreneur: For those of us adopting this role take on characteristics of entrepreneurs and business owners, ensuring the product meets customer needs and adds value to the market.
You may want to choose the Destination Development Path when you just want to build something useful and ship it. It doesn't have to be perfect and it can even be written in Cobol if thats what is going to help you ship the damn thing. Talk to users and make sure that you're building something that meets their needs. If you're building something no one wants to use, do Journey development or scrap the project.
There are situations where Destination Development is the more appropriate choice. For instance, when working on projects with tight deadlines, commercial applications, or those where there is a clear market need, shipping a reliable solution promptly is paramount.
In the Destination Development Path, the focus is on using familiar technologies and tools, reducing the learning curve and potential risks. By prioritizing efficiency and commercial viability, we can meet customer demands and, hopefully, achieve success.
Example: Building an Ecommerce Store with Familiar Technology
For an unfamiliar domain like building an ecommerce store, instead of learning a new technology like Flutter, we may opt to use familiar technology like JavaScript for frontend, backend, and even mobile, thereby focusing on shipping the product faster, even if its not the best "technical choice".
Choosing Both, or Hybrid Approaches:
It's important to recognize that Journey and Destination Development are not rigidly compartmentalized approaches. We can find success by blending elements of both philosophies to suit specific project requirements effectively. By leveraging the benefits of exploration and learning alongside the need for timely and reliable deliverables, we can create innovative solutions that are both well-informed and efficiently developed. Striking the right balance between the two approaches can enable us to grow professionally while catering to real-world needs.
Balancing Developer Satisfaction and User Needs:
Finding harmony between personal interests (in Journey Development) and meeting the needs of end-users (in Destination Development) is a critical consideration. While Journey Development allows us to delve into technologies and domains that intrigue them, Destination Development requires a focus on practical results and user satisfaction.
Striking a balance between these two aspects can lead to greater job satisfaction, as we can find meaning in their work while delivering valuable products to users. By aligning their interests with user needs, we can create products that are not only technically proficient but also genuinely beneficial.
Long-Term Development Strategies:
As we gain experience and expertise, our development philosophy might evolve over time. Engaging in a mix of Journey and Destination Development projects contributes to well-rounded skill development and a more versatile developer profile. By participating in both exploratory and goal-oriented projects, we can continuously grow their skillset and adapt to changing market demands.
That being said, identify when you just need to ship something and just do it. For me, it is far too easy to want to use any opportunity to learn new technology and do exploratory work. Sometimes it's just better to ship something and enjoy the dopamine hit from successfully shipping something.
Bringing it all together
Understanding the dichotomy between the Journey Development Path and the Destination Development Path empowers us to make informed decisions based on project goals, deadlines, and personal preferences. Each approach comes with its own merits and learning opportunities, and the choice largely depends on the developer's desired outcome. Striking a balance between exploration and shipping will contribute to our growth as developers as we navigate their unique software development journey.
