Interviewer: What is Good Technical Debt ?

Good technical debt is the intentional and thoughtful use of temporary shortcuts in a product's development to achieve short-term goals, like faster delivery or quick market validation. It’s taken with a clear plan to address it later and managed carefully to avoid long-term issues.

Good technical debt is most commonly used in the following scenarios:

1. Validating an Idea or MVP:

   • When building a Minimum Viable Product (MVP) to test an idea or gather user feedback, allowing rapid iteration without overengineering.

2. Meeting Tight Deadlines:

   • When a feature or product must be delivered quickly to meet a launch date, market opportunity, or business-critical deadline.

Example: Hardcoding Pricing Rules in a B2B SaaS Platform

Scenario in MY Product:
Our B2B SaaS platform needed a pricing feature to support tiered plans (e.g., Basic, Premium, Enterprise) for a quick market launch. Instead of building a robust pricing engine that dynamically calculates charges based on configurable rules, we hardcoded the pricing tiers directly in the system.

Why It Was Good Technical Debt:

1. Intentional: We decided to hardcode the pricing logic to meet a tight deadline for the product launch, knowing it could be replaced later.

2. Temporary: The hardcoded logic was documented, and our roadmap included plans to develop a flexible, rule-based pricing engine once we validated the tier structure.

3. Aligned with Goals: This approach allowed us to focus on onboarding customers quickly and testing whether the pricing tiers resonated with our target audience.

Outcome:
The platform launched successfully, customers adopted the pricing plans, and their feedback helped us refine the tiers. Later, we replaced the hardcoded logic with a dynamic pricing engine, ensuring scalability as our user base grew.

How to Explain This to an Interviewer:

1. Start with the Business Context: "In our B2B SaaS platform, we needed to implement tiered pricing for our product plans to meet a critical launch deadline."

2. Explain the Trade-Off: "Instead of building a full-featured pricing engine, we hardcoded the pricing rules, saving development time. This allowed us to go live and test the market response to the pricing plans."

3. Discuss the Plan for Resolution: "We documented the limitation and planned to develop a configurable pricing system in the next two sprints, once we validated the tier structure."

4. Highlight the Result: "The quick launch helped us onboard customers early and gather feedback, which guided us in designing a scalable pricing engine later."

Detailed Technical Implementation of the Hardcoded Pricing Logic Example

Phase 1: Quick Implementation (Hardcoding the Logic)

To save time and meet the product launch deadline, your team hardcoded the pricing logic directly into the application code.

1. Step 1: Define Pricing Rules

   • The team identified three tiers (e.g., Basic, Premium, and Enterprise) with fixed prices and specific feature access for each plan.

   • { "Basic": {"price": 50, "features": ["Feature A", "Feature B"]}, "Premium": {"price": 100, "features": ["Feature A", "Feature B", "Feature C"]}, "Enterprise": {"price": 200, "features": ["All Features"]} }

2. Step 2: Hardcode the Rules in the Codebase

   • The pricing rules were directly embedded into the application’s backend logic.

   • Example (in a Python-based backend)

   • def get_pricing_plan(plan_name): pricing_plans = { "Basic": {"price": 50, "features": ["Feature A", "Feature B"]}, "Premium": {"price": 100, "features": ["Feature A", "Feature B", "Feature C"]}, "Enterprise": {"price": 200, "features": ["All Features"]}, } return pricing_plans.get(plan_name, {"price": 0, "features": []})

3. Step 3: Quick Integration

   • Backend APIs used the hardcoded logic to calculate and return prices based on user-selected tiers.

   • @app.route('/api/get-pricing', methods=['GET']) def get_pricing(): plan = request.args.get('plan') return jsonify(get_pricing_plan(plan))

4. Step 4: Testing and Deployment

   • • Basic test cases verified the logic, such as:

       • Validating pricing for each tier.

       • Ensuring correct feature lists were returned for selected tiers.

This allowed the feature to be deployed in minimal time, ensuring a successful product launch.

Phase 2: Addressing the Technical Debt (Dynamic Pricing Engine)

Once the initial product validated the pricing structure, your team worked to replace the hardcoded logic with a scalable and configurable pricing engine.

1. Step 1: Database Design

   • The team created a database schema to store pricing plans and their associated features dynamically.

   • CREATE TABLE PricingPlans ( id INT PRIMARY KEY, name VARCHAR(50), price DECIMAL(10, 2) );

     CREATE TABLE PlanFeatures ( id INT PRIMARY KEY, plan_id INT, feature_name VARCHAR(100), FOREIGN KEY (plan_id) REFERENCES PricingPlans(id) );

2. Step 2: Backend Refactoring

   • The hardcoded logic was replaced with database queries to fetch pricing and feature data dynamically.

   • def get_pricing_plan_from_db(plan_name): plan = db.session.query(PricingPlans).filter_by(name=plan_name).first() features = db.session.query(PlanFeatures).filter_by(plan_id=plan.id).all() return { "price": plan.price, "features": [f.feature_name for f in features] }

3. Step 3: Admin Config Panel

   • Built an admin interface to allow business teams to update pricing plans and features without needing code changes.

   • Example:

     • Add/modify plans through an admin dashboard with form inputs for pricing and features.

4. Step 4: Testing and Deployment

   • Conducted thorough integration tests to ensure:

     • Pricing and features returned correctly.

     • The admin panel updates reflected dynamically in the frontend

5. Technical Benefits of the Upgrade

   • Scalability: Easily add, update, or remove pricing plans as the product evolves.

   • Flexibility: Supports region-specific pricing or promotional discounts without code changes.

   • User Empowerment: Business users manage pricing directly, reducing dependency on developers.