12/5/2024

Understanding when and where to invest in software quality, and how to build systems that last

Written by: Jonathan Haas

In my last post, I argued against perfectionism in startup environments. Today, I want to explore the other side of that coin: when quality really matters, and why craft isn’t just about satisfying our engineering ego.

The Cost of Moving Too Fast

While perfect shouldn’t be the enemy of good, there’s a corollary worth examining: quick-and-dirty shouldn’t be the enemy of sustainable. I’ve seen teams take the “move fast” mantra too far, creating problems that would haunt them for years:

1. Security vulnerabilities that remained hidden until a critical moment
2. Data inconsistencies that took months to untangle
3. Performance problems that drove away early adopters
4. Architecture decisions that made future changes nearly impossible

The Foundations That Matter

At ThreatKey, we learned that certain areas of our system demanded uncompromising quality from day one. These weren’t always obvious at first, but they became clear as we scaled:

1. Data Integrity

When handling security data, there’s no room for “we’ll fix it later.” Customer data needs to be reliable, consistent, and protected from the start. Refactoring data models after they’re in production is exponentially more difficult than getting them right initially.

// This isn't over-engineering, it's essential protection:
interface AuditEvent {
  readonly id: string;
  readonly timestamp: Date;
  readonly actor: Actor;
  readonly action: AuditedAction;
  readonly target: AuditTarget;
  readonly metadata: Readonly<Record<string, unknown>>;
}

2. Authentication and Authorization

Auth is another area where “MVP” thinking can be dangerous. We invested heavily in our permission system early, and it paid dividends as we added enterprise features:

• Role-based access control from day one
• Audit logging built into the core
• Clear separation between authentication and authorization logic

3. API Design

Public APIs are like contracts - breaking changes can destroy trust. We learned to treat API design with the respect it deserves:

• Careful versioning strategy
• Extensive documentation
• Thoughtful error handling
• Clear deprecation policies

Quality as a Competitive Advantage

In certain markets, quality itself becomes a key differentiator. For security tools like ThreatKey, customers actively evaluate:

• System reliability
• Performance under load
• Data accuracy
• Error handling
• Edge case management

These aren’t nice-to-haves; they’re core purchase criteria. In such markets, cutting corners on quality isn’t just technical debt - it’s market debt.

The Art of Strategic Quality

The key is developing what I call “quality intuition” - knowing where to invest in excellence and where to accept good enough. Here’s my framework:

High-Quality Zones

1. Core Business Logic: The features that directly deliver your main value proposition
2. Data Management: Anything touching customer data
3. Security Components: Authentication, authorization, encryption
4. Public Interfaces: APIs, integration points, data exports
5. Performance-Critical Paths: High-traffic or resource-intensive operations

Flexible Zones

1. Internal Tools: Admin panels, debugging interfaces
2. Feature Experiments: New capabilities being tested
3. Single-Customer Features: Functionality built for specific use cases
4. Non-Critical Workflows: Error-tolerant processes
5. Temporary Solutions: Stopgap measures with clear replacement plans

Building Quality Culture

Quality isn’t just about code - it’s about culture. Here’s how we foster it:

1. Code Review Standards: Clear guidelines about what constitutes acceptable quality
2. Testing Expectations: Defined coverage requirements for different parts of the system
3. Documentation Requirements: Especially for core systems
4. Technical Design Reviews: For significant architectural decisions
5. Post-Incident Learning: Using failures as teaching moments

The ROI of Quality

Quality investments compound over time:

• Reduced Support Burden: Well-built systems generate fewer tickets
• Faster Feature Development: Clean code is easier to extend
• Higher Team Morale: Engineers take pride in solid work
• Customer Trust: Reliability builds relationships
• Reduced Technical Debt: Less rework needed

Finding Your Quality Balance

Every team needs to find its own quality equilibrium. Here’s how to start:

1. Map Your Quality Zones: Identify where quality really matters
2. Set Clear Standards: Define what “good enough” means in different contexts
3. Create Quality Feedback Loops: Regular system health checks
4. Measure Quality Impact: Track metrics that matter
5. Adjust Continuously: Evolve standards as you learn

When It Matters

The art of software engineering isn’t about choosing between speed and quality - it’s about knowing when each matters most. Build too fast everywhere, and you’ll create a house of cards. Build too carefully everywhere, and you’ll never ship. The magic happens when you can do both: move fast where speed matters, and build solid where quality counts.

The next time someone says “we need to move faster,” ask them what they’re willing to sacrifice. And the next time someone insists on perfection, ask them what they’re willing to delay. The answers to those questions will guide you to the right balance for your team and product.