Business Problems vs. Programming Problems

A colleague was once stuck on a task that was taking forever to resolve. Every day, he would say that he was making progress, only to later report that the solution didn't pan out. He was looking through different solutions he found online and was experimenting. After some time, I was tasked to help him get it resolved. The problem was to make sure the cash backs and cash forwards were properly calculated.

Looking at his work and different attempts, I quickly found the problem. The issue he was working on wasn't a programming problem at all. It was a business problem in disguise. It's crucial to make this distinction so we can better approach these challenges.

A Classic Business Problem

On the surface, calculating taxes seems straightforward: total_amount * tax_rate. Easy, right? Not so fast. The real complexity isn't in the multiplication itself, but in the dozens of business rules that dictate how that calculation should happen:

• Does the total include shipping costs? This is a huge one! Some states tax shipping, others don't, and some companies have internal policies on how they handle it.
• What's the general rule for your company? Even if state laws are clear, your business might have a specific interpretation or a simplified approach for certain scenarios.
• Do you add taxes before or after discounts? Another common scenario that requires a business decision.
• What if the customer is tax-exempt? This involves validating tax-exempt status, which is a business process, not a programming one.
• How do you handle returns and refunds with taxes? Reversing tax calculations correctly is a business rule, not a technical implementation detail.

The solution to these questions isn't found in a programming language or an algorithm. It's found in company policy, legal interpretation, and financial strategy. A developer can implement the calculation, but they can't decide the rules. That falls squarely on the shoulders of product managers, legal teams, and finance departments.

To further illustrate, consider these scenarios often mistaken for programming problems:

• User Account Deactivation: A developer can write the code to deactivate an account. But what happens when an account is deactivated? Does it get soft-deleted? Hard-deleted after a certain period? Are associated user-generated content or historical data retained? Is the username freed up immediately? These are all business decisions that impact the system's behavior and user experience.
• Defining "Active User": How do you define an "active user" for reporting purposes? Is it someone who logs in daily? Someone who performs a specific action weekly? The programming task is to count users based on criteria, but the criteria themselves are defined by business needs for analytics and growth tracking.
• Content Moderation Rules: A developer can build a system to filter out offensive content. But what constitutes offensive content? What are the thresholds for flagging? What actions should be taken (hide, warn, ban)? These are complex ethical and business policy decisions.
• Promotional Eligibility: Who qualifies for a specific discount or promotion? Is it new users only? Users who haven't purchased in six months? Users in a specific region? The logic to check eligibility is programming, but the eligibility criteria are business rules.

Programming Problems: Where Developers Shine

In contrast, programming problems are about the how of technical implementation. These are the challenges where your expertise as a developer is paramount, and the decisions are largely yours to make within technical constraints.

You provided excellent examples:

• API Implementation: How do you structure the endpoints? What authentication method will you use? How will you handle error responses? These are technical choices that impact the efficiency, security, and usability of the API, and they're within the developer's domain.
• Technical Debt Resolution: Deciding how to refactor a messy piece of code, choosing the right design pattern to improve maintainability, or optimizing a slow database query. These are all technical decisions aimed at improving the underlying system.
• Choosing a Cache: Whether you use Redis or Memcached (or another caching solution) is a classic programming problem. The product manager doesn't care about the specifics of your caching layer; they care that the application is fast and responsive. Your decision is based on performance needs, data persistence requirements, ease of use, and existing infrastructure.
• Database Schema Design: How do you normalize your tables? What data types should you use? How do you index for performance? These are technical decisions to ensure data integrity and efficient querying.
• Optimizing an Algorithm: If a process is too slow, the programming problem is to find a more efficient algorithm or data structure to achieve the same result.

---

Ask the Right Questions

The solution to my colleagues' issue wasn't to come up with the perfect algorithm. Instead it was to ask the business team to clearly define how cashback is calculated so it can be implemented in code.

The key takeaway for developers is to learn to identify when a problem transitions from a programming challenge to a business decision. Before you dive deep into endless research or complex technical solutions, pause and ask yourself:

• "Is the answer to this question something I can find in documentation, a library, or by writing code, or is it something that requires a policy to be set?"
• "Am I trying to figure out what to do, or how to do what has already been decided?"
• "Whose input do I really need to move forward on this task?"

By understanding this distinction, you can save countless hours, avoid unnecessary frustration, and ensure that you're focusing your valuable technical skills on the problems that truly require them. It also empowers you to push back appropriately, asking for clarity on business rules rather than trying to invent them yourself.

---