Coding With Constraints - Equilateral AI

The Reality of Software Development

Every software project exists within constraints. Time constraints. Budget constraints. Technical constraints from legacy systems. Organizational constraints from team structure and skill sets. The art of professional software development lies not in creating perfect solutions, but in creating the best possible solutions within these constraints.

Perfect is the enemy of good, but good is the enemy of shipping. The skill is knowing where to draw the line.

This isn't about accepting poor quality code or cutting corners. It's about making deliberate, informed trade-offs that deliver value while maintaining long-term system health.

Types of Development Constraints

Technical Constraints

Legacy System Integration: Working with 15-year-old APIs that can't be changed
Technology Stack Limitations: Being locked into specific frameworks or languages
Performance Requirements: Sub-second response times with limited infrastructure budget
Data Consistency: Maintaining integrity across distributed systems without transactions

Business Constraints

Fixed Deadlines: Product launches, regulatory compliance, seasonal events
Budget Limitations: Limited development time, infrastructure costs, third-party services
Compliance Requirements: SOX, GDPR, HIPAA, industry-specific regulations
User Experience Non-negotiables: Features that must work exactly as specified

Organizational Constraints

Team Skill Sets: Working with the team you have, not the team you want
Communication Boundaries: Conway's Law in action across departments
Risk Tolerance: Conservative organizations vs. move-fast-and-break-things cultures
Knowledge Silos: Critical system knowledge held by one person

Constraint-Driven Design Patterns

The Strangler Fig Pattern

When you can't replace a legacy system all at once, you gradually strangle it with new functionality:

// Legacy system handling 80% of traffic
// New system gradually taking over specific routes
const routeHandler = (request: Request) => {
  if (isNewFeature(request.path)) {
    return newSystem.handle(request);
  }
  
  if (isLegacyMigrated(request.path)) {
    return newSystem.handle(request);
  }
  
  return legacySystem.handle(request);
};
          

The Good Enough Cache

Sometimes a simple in-memory cache is better than an over-engineered distributed cache:

// Not perfect, but solves 95% of the performance problem
const simpleCache = new Map();

const getCachedData = (key: string) => {
  const cached = simpleCache.get(key);
  if (cached && cached.expiry > Date.now()) {
    return cached.data;
  }
  
  const freshData = expensiveOperation(key);
  simpleCache.set(key, { 
    data: freshData, 
    expiry: Date.now() + 300000 // 5 minutes
  });
  
  return freshData;
};
          

The Graceful Degradation Strategy

Build systems that work imperfectly rather than fail completely:

const getRecommendations = async (userId: string) => {
  try {
    // Try the ML recommendation engine
    return await aiRecommendationService.getRecommendations(userId);
  } catch (error) {
    // Fall back to simple popularity-based recommendations
    console.warn('AI service unavailable, using fallback', error);
    return await getPopularItems(userId);
  }
};
          

Working with Legacy Code

Most professional development involves working with existing systems that weren't designed for your current requirements.

The Characterization Test Strategy

When you inherit code without tests, start by characterizing what it actually does:

// Legacy function that "calculates shipping cost"
// No one knows exactly how it works
const calculateShipping = (order: any) => {
  // ... 200 lines of mysterious business logic
  return someComplexCalculation;
};

// Characterization test - document what it currently does
test('calculateShipping behavior', () => {
  // Not testing if it's correct, just that it's consistent
  expect(calculateShipping(standardOrder)).toBe(12.50);
  expect(calculateShipping(internationalOrder)).toBe(45.00);
  expect(calculateShipping(bulkOrder)).toBe(8.75);
});
          

The Seam Strategy

Find natural boundaries in legacy code where you can inject new behavior:

// Legacy code that's hard to test
class OrderProcessor {
  processOrder(order: Order) {
    // ... complex logic
    this.sendEmail(order.customerEmail, emailContent); // <- Seam!
    // ... more complex logic
  }
  
  // Make this method virtual/overridable for testing
  protected sendEmail(email: string, content: string) {
    emailService.send(email, content);
  }
}
          

Time Constraint Strategies

The MVP Mindset

Minimum Viable Product isn't about building something minimal - it's about building the minimum thing that provides value:

Feature Complete vs. Experience Complete: Core functionality working vs. polished experience
Manual vs. Automated: Sometimes a human process is faster to implement than automation
Hard-coded vs. Configurable: Start with constants, add configuration when needed
Synchronous vs. Asynchronous: Start simple, optimize for scale later

The Technical Debt Ledger

Not all technical debt is bad. Track it deliberately:

// TODO: DEBT - Replace with proper queue system when we hit 1000 orders/day
// Current simple approach handles ~100 orders/day reliably
// Estimated fix time: 2 weeks
// Business impact if not fixed: Manual intervention required at scale
const processOrderQueue = orders.map(order => processOrder(order));
          

Technical debt is like financial debt - it's a tool. Used wisely, it enables faster delivery. Used carelessly, it compounds into a crisis.

Quality vs. Speed Trade-offs

The Testing Pyramid Under Pressure

When time is short, be strategic about testing:

Happy Path Integration Tests: Cover the core user journey first
Unit Tests for Business Logic: Test calculations, validations, and transformations
Manual Testing for UI: Sometimes faster than automating, especially for one-time features
Monitoring as Testing: Deploy with comprehensive monitoring and alerts

Code Review Under Constraints

Focus reviews on what matters most:

Security vulnerabilities - Always worth the time
Performance bottlenecks - Hard to fix after deployment
API contracts - Changes are expensive later
Business logic correctness - Wrong calculations compound over time
Style and formatting - Use automated tools, not human review time

Communication Strategies

Explaining Technical Constraints to Non-Technical Stakeholders

Translation is a core skill for constraint-driven development:

"We can build feature X in 2 weeks, but it won't scale past 100 users. Or we can spend 6 weeks building it properly to handle 10,000 users. What's your user growth timeline?"

The Options Framework

Always present constraints with options:

Fast: Quick implementation with known limitations
Good: Solid implementation that meets current requirements
Right: Comprehensive solution that handles future growth

Let stakeholders choose which constraint to relax: time, scope, or quality.

Tools for Constraint-Driven Development

Decision Records

Document the constraints that led to architectural decisions:

# ADR-001: Use Redis for Session Storage

## Context
- Need session persistence across multiple server instances
- Budget constraint: Can't afford dedicated session management service
- Time constraint: Must ship in 2 weeks
- Team constraint: No experience with complex session solutions

## Decision
Use Redis for session storage with simple key-value approach

## Consequences
- Positive: Fast, simple, meets immediate needs
- Negative: Single point of failure
- Mitigation: Plan Redis clustering for Q3 when budget allows
          

Constraint Tracking

Keep a living document of active constraints and their expiration dates:

Technical: "Using SQLite until we hit 1000 concurrent users"
Business: "Manual approval process until compliance audit completes"
Resource: "Single server deployment until Q2 budget approved"

🧠 Coding With Constraints