The Primary Responsibility of a Software Engineer: Delaying Decisions

At the heart of software engineering, our most visible task is building the features that businesses rely on. We work closely with stakeholders to develop the functionality that drives the business forward, whether it’s handling payments, managing customer data, or delivering personalized experiences to users. Delivering these features is critical, but it’s not the most important part of the job.

I believe that the primary responsibility of a software engineer is to design systems that give the team flexibility to delay certain key decisions until later, when there's more information available. Delaying decisions may sound counterintuitive, but it's a strategy that can significantly reduce risk, increase adaptability, and ultimately lead to more robust systems.

Software development is full of uncertainties: business needs evolve, user behavior changes, data volume grows, and new technologies emerge. If we make key decisions too early - such as selecting a database, cloud provider, or framework - we may lock ourselves into choices that limit flexibility in the future. What might work well for a small project or MVP (Minimum Viable Product) could break down as the system scales or as business requirements change.

The Importance of Delaying Decisions

Making decisions with incomplete information can lead to technical debt. When we choose technology or architecture early on, it's often based on assumptions about how the system will behave in the future. But reality rarely matches those assumptions. By postponing decisions, we reduce the risk of locking ourselves into choices that don't hold up as the project evolves.

Take, for example, the decision of choosing a database. At the start of a project, you might not have a clear picture of the types of queries you'll need, the volume of data you'll store, or the complexity of relationships in the data. Committing to a specific database early could cause issues if the project later requires more complex querying, higher scalability, or better indexing. By delaying this decision - perhaps starting with an abstracted data access layer - you give yourself the flexibility to switch to a different database later without reworking large parts of the codebase.

Delaying decisions isn't about avoiding responsibility or kicking the can down the road. It's about waiting for the right time to make decisions - when you have more clarity on the system's real needs. This leads to better, more informed choices that are sustainable in the long term.

How to Delay Decisions: Abstraction and Isolation

The key to effectively delaying decisions is through abstraction and isolation. By isolating different layers of the system and abstracting them from one another, you can minimize the impact of changes to one part of the system when it's time to make a decision.

For instance, in the case of choosing a cloud provider, many companies start by tightly integrating their systems with specific services offered by platforms like AWS, Google Cloud, or Azure. But what happens if the business later wants to migrate to a different provider for cost reasons or regulatory compliance? If the system is tightly coupled to a single provider's APIs, switching becomes a painful and costly process. However, by abstracting cloud-specific logic behind interfaces or adopting cloud-agnostic solutions like Kubernetes, you delay the decision of committing fully to one provider. This gives you the flexibility to migrate or expand to multiple providers when the need arises, without significant rework.

Abstraction can also apply to logging, monitoring, or even authentication. Instead of choosing a logging framework early on and embedding it deep in your business logic, you can abstract logging behind a common interface. This allows you to start with a basic logging mechanism during development and later switch to a more advanced solution (like ELK stack or Datadog) as the project scales - without modifying the core of your application.

Balancing with the Secondary Responsibility: Delivering Features

While the primary responsibility is about creating flexibility and future-proofing systems, the secondary responsibility of a software engineer is just as important: delivering features.

The business requires functionality to meet immediate goals - whether it's releasing a new product feature, enabling a payment system, or building an internal tool for operations. These features directly contribute to the value of the business, and it's our job to implement them efficiently and with quality. After all, the system won't be useful if it doesn't deliver the functionality that users and stakeholders need.

However, delivering features can sometimes be at odds with the goal of delaying decisions. There is often pressure to deliver quickly, and it can be tempting to hardcode specific choices or skip the abstraction process to speed things up. For example, an engineer might choose a specific third-party authentication provider and tightly integrate it into the code, believing that this will get the feature done faster. And in the short term, it might. But if the business later decides to switch providers, or add support for multiple authentication methods, the tightly-coupled implementation will lead to costly refactoring.

This is where balancing both responsibilities becomes critical. While it's necessary to deliver features to meet business needs, engineers must ensure that those features are delivered in a way that keeps the system flexible. Abstracting key parts of the system and keeping components loosely coupled allows features to be built without locking the system into decisions that may no longer make sense in the future.

For example, while delivering a feature that involves user data storage, we might opt to use an abstracted data layer that allows us to switch databases later, rather than committing to one specific database right away. This way, we deliver the feature while still keeping the system adaptable for future changes.

Why Delaying Decisions and Delivering Features Go Hand-in-Hand

Ultimately, the two responsibilities - delaying decisions and delivering features - are not in conflict; they complement each other. By building systems that allow decisions to be postponed, engineers reduce the risk of technical debt and future-proof the system. And by delivering features thoughtfully, with abstraction and flexibility in mind, we ensure that business needs are met without compromising long-term adaptability.

When both responsibilities are managed effectively, we create systems that deliver immediate business value through features that work well today. At the same time, these systems remain flexible and adaptable to future changes, allowing key decisions to be made when the right time comes.

A strong software engineer understands that delivering features isn't just about solving today's problems - it's about ensuring that the system can grow and evolve smoothly in the future. This mindset leads to more maintainable, scalable, and resilient systems.

Conclusion: A Balance for Sustainable Software Development

In summary, while delivering features is critical and serves the immediate needs of the business, the primary responsibility of a software engineer is to design systems that give the team the flexibility to make better decisions in the future. By abstracting key components, decoupling systems, and postponing decisions like choosing a database or cloud provider, we can create adaptable systems that evolve smoothly as requirements change.

Balancing both responsibilities ensures that we're not only meeting the business's current needs but also protecting the long-term health and scalability of the system. In doing so, we set our teams up for success, now and in the future.

Thank you for reading! Feel free to leave your comments below, and let’s stay connected on LinkedIn or follow me on Twitter or Github for more insights and updates.