Development Lifecycle Trade-offs

Every development lifecycle decision involves trade-offs. The review board expects candidates to articulate what is gained and what is sacrificed with each choice.

How to present trade-offs

Use the formula: “I chose [option] because [scenario-specific reason]. The trade-off is [downside], which I mitigate by [mitigation].” This demonstrates you considered alternatives and can defend your position.

---

1. Agile vs Waterfall

Figure 1. A Hybrid approach satisfies regulatory gate requirements without locking the team into sequential waterfall execution. Sprints run within each phase while formal sign-offs happen at phase boundaries. This is the most common recommendation for regulated-industry CTA scenarios.

CTA scenarios rarely have a single “right” answer here. The choice depends on the customer’s organizational maturity, timeline, and risk tolerance.

Dimension	Agile (Scrum/SAFe)	Waterfall
Feedback speed	Every 2-week sprint	After full build (months)
Scope flexibility	High, backlog reprioritized continuously	Low, scope locked after requirements phase
Risk discovery	Early, working software each sprint	Late, issues found in UAT or later
Documentation	Lighter, living docs	Heavy upfront documentation
Stakeholder involvement	High and continuous	Front-loaded, then review gates
Team maturity required	Self-organizing, cross-functional	Defined roles, sequential handoffs
Budget predictability	Variable, scope adjusts to budget	Fixed, budget tied to signed scope
Compliance readiness	Requires discipline for audit trails	Naturally creates audit-ready artifacts
CTA scenario frequency	Very common; most scenarios assume agile	Appears in regulated or government scenarios

When Each Side Wins

Agile wins when requirements are evolving, stakeholders are available for regular feedback, the team is experienced with iterative delivery, or the project has high uncertainty.

Waterfall wins when regulatory requirements demand formal sign-offs at each stage, the scope is truly fixed and well-understood, the organization lacks agile maturity, or contractual obligations require upfront deliverables.

Hybrid approach: Many CTA scenarios benefit from a hybrid. Waterfall provides the overall program structure (milestones, gates) while agile sprints handle execution within each phase. This satisfies compliance while maintaining delivery velocity.

---

2. Change Sets vs CLI (Salesforce DX)

Dimension	Change Sets	Salesforce CLI (sf)
Learning curve	Low, point-and-click in Setup	Higher, command line and project structure
Repeatability	Manual, must recreate each time	Automated, scripted and version-controlled
CI/CD compatibility	None, cannot automate	Full, integrates with any CI/CD tool
Rollback	Destructive changes only, no true rollback	Version control enables rollback
Team collaboration	Sequential, one deployer at a time	Parallel, merge workflows
Metadata coverage	Limited subset of metadata types	Broader metadata coverage
Audit trail	Deployment history in Setup	Git history, PR reviews, pipeline logs
Org complexity	Sufficient for simple orgs	Required for complex, multi-team orgs

When Each Side Wins

Change sets win when the team is small (1-2 admins), the org is simple, deployments are infrequent, there is no CI/CD requirement, or the team is admin-heavy without CLI experience.

Salesforce CLI (sf) wins when multiple developers are involved, the metadata is complex, a CI/CD pipeline is needed, unlocked packages are in use, or audit requirements demand git history.

CTA board expectation

The board expects CTAs to recommend Salesforce DX for any enterprise-scale scenario. Recommending change sets for a complex, multi-team implementation raises concerns about architectural maturity. Acknowledge that change sets may coexist during a transition period, but the direction must be toward source-driven development.

---

3. Full Copy vs Partial Copy Sandbox

Dimension	Full Copy Sandbox	Partial Copy Sandbox
Data fidelity	Production-identical data	Sampled subset via sandbox templates
Refresh time	Hours to days for large orgs	Minutes to hours
Storage cost	Matches production	Fraction of production storage
License cost	Included with Unlimited/Performance (EE requires separate purchase)	More available per edition
Testing realism	Highest, real data volumes and relationships	Lower, may miss edge cases in data
Data sensitivity	Contains real PII/PHI; requires masking	Smaller attack surface but still needs masking
Refresh frequency	Limited (29-day interval)	More frequent refreshes possible
LDV testing	Accurate performance testing	Cannot test real data volume behavior

When Each Side Wins

Full copy wins when performance testing requires realistic data volumes, UAT needs production-identical data, data migration must be validated, or integration testing depends on real data relationships.

Partial copy wins when the work involves development, unit testing, training environments, or cost-constrained projects. It also wins when data privacy regulations make full copy impractical without a large masking investment.

The masking question

The CTA board frequently asks about data masking. Always mention post-copy scripts (Sandbox Post Copy Apex) for masking sensitive data regardless of sandbox type.

---

4. Manual vs Automated Testing

Dimension	Manual Testing	Automated Testing
Setup cost	Low, no tooling needed	High: framework, scripts, maintenance
Execution speed	Slow, human-paced	Fast, runs in minutes
Regression coverage	Inconsistent, depends on the tester	Consistent, same tests every time
Exploratory value	High, humans find unexpected issues	Low, only tests what is scripted
Maintenance burden	None (ad hoc)	Ongoing; tests break as UI/logic changes
CI/CD integration	Cannot gate deployments	Gates deployments automatically
Scalability	Linear cost (more testers = more cost)	Fixed cost after initial investment
Confidence level	Variable	High and measurable

When Each Side Wins

Manual testing wins when the goal is exploratory testing, UX validation, complex business process verification, one-time migration validation, or early-stage projects where automation ROI is unclear.

Automated testing wins when the need is regression testing across releases, CI/CD pipeline gating, high-frequency deployments, large test suites, or long-running projects where the automation investment pays off.

For board scenarios: Present a test pyramid with automated unit tests at the base (Apex test classes, 75%+ coverage), automated integration tests in the middle, and manual exploratory/UAT at the top. This shows a balanced, cost-effective strategy.

---

5. Centralized vs Federated Center of Excellence (CoE)

Figure 2. Shared customer data across business units is a forcing function for the Hybrid model, because consistent data governance requires a central authority even when BUs want full autonomy. When BUs have isolated data domains and mature teams, a Federated CoE avoids the central bottleneck.

Dimension	Centralized CoE	Federated CoE
Governance strength	Strong, single authority	Variable, depends on BU compliance
Standards consistency	High, one set of standards	Risk of divergence across BUs
Speed of delivery	Slower, bottleneck at central team	Faster, BU teams self-serve
Knowledge concentration	Risk of single point of failure	Knowledge distributed across org
Cost	Lower headcount, shared resources	Higher, each BU needs expertise
Innovation	Controlled, methodical	Faster experimentation at BU level
Scalability	Bottleneck as org grows	Scales with organization
BU autonomy	Low, must go through central team	High, BUs own their roadmap

When Each Side Wins

Centralized wins when the organization is small/medium, compliance requirements are strict, customer data is shared across BUs, Salesforce expertise is limited, or the org is early in its Salesforce journey.

Federated wins when the organization is large with independent BUs, business processes differ significantly, there are multiple orgs, BUs have mature Salesforce teams, or delivery speed takes priority over consistency.

Hybrid model: Most enterprise CTA scenarios benefit from a “hub and spoke” model. A central CoE sets standards, manages shared components, and governs architecture decisions while BU teams execute within those guardrails.

---

6. Short vs Long Release Cycles

Dimension	Short Cycles (2-4 weeks)	Long Cycles (Quarterly+)
Feedback incorporation	Rapid, issues fixed quickly	Slow, feedback waits for next release
Risk per release	Low, small change sets	High, large change sets with more unknowns
Testing burden	Lighter per release	Heavy, full regression each cycle
Coordination overhead	Continuous, always releasing	Concentrated, big release events
User disruption	Frequent small changes	Infrequent but larger disruptions
Rollback complexity	Simple, small delta to revert	Complex, large delta with dependencies
CI/CD requirement	Essential	Nice-to-have (can deploy manually)
Salesforce release alignment	Can react to platform releases quickly	May conflict with 3x yearly Salesforce releases

When Each Side Wins

Short cycles win when CI/CD is mature, automated testing is in place, business requires rapid feature delivery, or the team follows DevOps practices.

Long cycles win when regulatory change management requirements apply, testing resources are limited, multi-system deployments require coordination, or the organization has formal CAB processes.

Salesforce release cadence

Salesforce releases 3 times per year (Spring, Summer, Winter). The release strategy must account for these platform updates. Short cycles absorb platform changes incrementally; long cycles must plan for potential breaking changes in a single big effort.

---

Trade-off Analysis Framework

Use this template when analyzing any dev lifecycle trade-off at the board:

Step	Question	Example
1	What is the business driver?	”Need to deploy weekly to respond to market changes”
2	What are the options?	”Short release cycles with CI/CD vs quarterly releases”
3	What does each option optimize for?	”Speed and risk reduction vs coordination simplicity”
4	What does each option sacrifice?	”Short cycles need CI/CD investment; long cycles delay feedback”
5	What does the scenario context favor?	”Multiple teams, evolving requirements favor short cycles”
6	What is the mitigation for the trade-off?	”Invest in automated testing to support short cycles”
7	What is the recommendation?	“2-week sprints with automated deployment pipeline”

---

Cross-Domain Connections

Dev lifecycle trade-offs connect to other domains:

• Declarative vs Programmatic: deployment complexity differs dramatically between declarative config and custom Apex
• Integration Trade-offs: integration deployment adds pipeline complexity (connected app configs, API versioning, middleware releases)
• System Architecture Trade-offs: org strategy decisions (single vs multi-org) multiply deployment pipeline complexity

---

Sources

• Salesforce DX Developer Guide
• Salesforce DevOps Center
• Trailhead: Org Development Model
• Salesforce Architect: Environment Strategy
• Sam Newman, “Building Microservices” (deployment patterns)
• Gene Kim et al., “The Phoenix Project” (DevOps principles)
• CTA coaching community notes on dev lifecycle trade-offs