In product development, the decisions made to tackle immediate challenges can shape the future of the product. Quick fixes and short-term solutions might solve problems for now but can lead to technical debt and long-term headaches. Understanding whether a decision is a “one-way door” or a “two-way door” helps teams make better choices, balancing speed and flexibility.
A one-way door decision is hard to reverse, like picking the architecture of a system. Once you go through, it’s tough and costly to go back.
A two-way door decision, however, can be easily undone. You can try something out and, if it doesn’t work, roll it back with little consequence. Knowing which type of decision you’re dealing with can save a lot of time and headaches.
Lets look at some examples where these decisions come to play.
1. Choosing a Cloud Provider
In software development, selecting a specific cloud provider like AWS, Azure, or Google Cloud is often considered a one-way door decision. Once you build your infrastructure on a particular provider, your systems, such as storage, databases, and authentication, can become deeply integrated with that provider’s tools and services.
As your application grows, switching to a different cloud provider becomes increasingly difficult and costly due to the effort required to migrate data, refactor code, and redeploy services.
But can we transform this into a two-way door decision by making strategic choices that minimize vendor lock-in? Perhaps if we split it down to the services we opt in for, we can then approach this module by module.
Databases
- One-Way Door: If you use databases like Amazon DynamoDB that are owned by Amazon, you become heavily dependent on AWS services.
- Two-Way Door: Opt for open-source databases like PostgreSQL or MySQL, which are supported across all major cloud platforms. This makes migrating your database to another provider more straightforward.
Authentication
- One-Way Door: Implementing authentication with services like AWS Cognito binds your user management to AWS.
- Two-Way Door: Use standard protocols like OAuth 2.0 for authentication. These standards are universally supported, allowing you to switch providers without overhauling your authentication system.
Storage
- One-Way Door: Directly integrating with services like Amazon S3 can make switching storage providers complex.
- Two-Way Door: We make it a two-way door by adding more configurations in the middleware. This flexibility allows our storage system to use interfaces or middleware that can interact with different storage services. So, if we decide to switch from Amazon S3 to Google Cloud Storage, we only need to adjust some settings in the middleware, and the code changes are minimal.
By adopting these strategies, you keep the door open to switch cloud providers in the future without incurring significant costs or risks. It does vary, case by case, as you may find the expertise and cost of maintenance and support also factor in when selecting a vendor.
Perhaps it might be even easier to diagnose issues and have a relationship manager assigned to you as you partner with a vendor. So, while vendor lock-in might be a one-way decision, weigh the choice in the long run.
2. The Scope of the Project
Let’s take a project that has the requirement integrate a third party auth provider API, aimed to simplify authentication with just one click. The platform chosen when the project started was Google (almost everyone has a google account nowadays, so why not?).
However, the idea didn’t end there. Having confidence in our compact team, the decision was made to integrate all providers like Apple, Microsoft, LinkedIn and Facebook. This not only created an increase in scope, but also in the timeline and complexity of the project.
So, if we take a step back and look what happened and what could have been done.
- One-Way Door: The team’s decision to expand the application to work with all providers increased the project’s scope and complexity. Once resources were allocated and work commenced on integrating multiple providers, reversing this decision would have meant wasting substantial time and effort already invested. The sunk cost fallacy of the one-way door decision started to creep in. The irreversible nature of this decision led to challenges that the small team couldn’t handle.
- Two-Way Door: Be agile. Focus on one provider and get it out. Perhaps take a survey of users to understand which provider they would use the most. If any issues occurred or if the project didn’t proceed as planned, you could easily pivot, and even change the project’s direction without significant loss. This decision can be reversible and provided the flexibility to adapt based on the project’s progress and findings.
3. Choosing a Framework/Language
Our team decides to use a specialized web framework like Laravel for their new application. Laravel is known for its structure and conventions that streamline development but every small feature requires following the MVC pattern.
Once the application is built using Laravel, it becomes challenging to switch to a different framework without a complete rewrite.
- One-Way Door: The codebase, plugins, and even team skills become tightly coupled with this framework. If, later on, the team finds that Laravel does not scale well for their needs or lacks support for certain features, moving to another framework like Django or Node.js would be a time-consuming and expensive process.
- Two-Way Door: Building prototypes, do early testing, and choose modular technologies. This way you could easily reverse the decision if the framework didn’t meet your needs, avoiding major setbacks.
Final Thoughts
By figuring out whether you’re need to go with a one-way or two-way door decision, you can decide how much time and effort to put in.
- Research Available Options: Reduce the list of frameworks or technologies by thoroughly researching those that can achieve your goals.
- Consult Experts: Reach out to expertise in specific frameworks or technologies for clarity on which to choose.
- List All Features: Before starting development, list all features you want to integrate into the app. This aids in framework selection and project planning.
Opt for two way decisions when you are unsure and want to keep things simple, test ideas, see what works, and make changes if needed.
But one-way doors, like major architecture decisions, are important to plan carefully to avoid making choices that are tough to undo. Slow down, debate, and thoroughly consider these decisions.
In both software and product management, knowing when to experiment and when to be cautious can help keep the product moving forward without creating unnecessary roadblocks in the future.
