Why is delivering software so hard?

Delivering software to customers on-time and with the expected quality is a big challenge.  The balance of scope, time, and resources is difficult to maintain for many teams. Unfortunately, many teams do not understand the main risk drivers for project schedule, effort, and cost.

Yet, projects that go off-path often have a similar trajectory:

1. development team strains to build system under pressure, cutting “a few” corners
2. project launches (late) and disappoints customers
3. entire organization spends months handling and fixing problems to win customers back

What if teams knew the risk drivers of project delivery and how to avoid them?

Late nights, schedule slips, cancellation, and disappointment are not foregone conclusions!

Risk Drivers

In The Economics of Software Quality, software quality luminary Capers Jones’ demonstrates that:

• the primary driver of software delivery cost and risk is the size of the project.
• one of the main risks in software delivery is that the project will not deliver software that provides value at all or will do so late.
• low quality or inability to put a complete set in place of working functionality is one of the primary issues blocking delivery.

Jones summarizes the probability of cancellation and schedule slippage for software projects by size and quality level in the following charts:

The charts’ x-axes express project size in Function Points, a standardized unit of software size analogous a Story Point.  The charts’ y-axes have log-linear scales.

The ‘Development Schedule’ chart depicts an increase in development schedule as the size of the project grows, as most managers would expect.

What managers may not expect is that projects with high quality:

• are cancelled 3-4x less than projects with low quality
• complete quicker across the entire domain of project sizes

Quality is better than “free.”  Building high-quality software reduces the time and effort required to deliver the project.  Projects with poor quality cost 10 or 20% more because the project schedule extends when staffing is highest or adds staff in the “push to the finish line” (c.f. Mythical Man Month).

Since the best case scenario of a low quality project is increased costs and worst case is cancellation, how can leaders tell if a project is in the midst of a quality crisis?

The leading symptoms of low quality software are:

1. poor or unpredictable customer experience
2. long test cycles and uncertain delivery dates
3. high percentage of time and effort spent fixing defects
4. frequently exceeding time and resource budgets

Taking Action

Deliver software on-time, with less drama.

Imperfect humans use imperfect knowledge and imperfect tools to build…imperfect systems.  We should accept that defects will occur and organize the project and SDLC to reduce the cost and drama of software delivery:

1. decompose software system into manageable, well-encapsulated modules
2. systemically detect and repair defects near to their introduction

Decompose System to Manage Size

The most-powerful strategy is to decompose the system into manageable, well-encapsulated modules.  The goal should be to create or extract components comprehensible by the development team and with a fully-independent software delivery lifecycle.  Restated, develop, test, and release components within the system independently of other components within the system using well-defined interfaces.

Extracting components from an existing monolithic system is challenging and must be done very carefully to preserve existing behavior, especially when the existing system already exhibits symptoms of poor quality.

There are a number of tactics to employ when performing the decomposition:

• use the “Strangler” design pattern to reroute service traffic from existing location to new
• investigate existing behavior carefully and reimplement explicit and implied interface contract
• establish a comprehensive, data-driven functional test suite for the extracted functionality
• mirror test or production traffic from the old implementation to the new and compare results

Detect & Repair Quickly to Improve Quality

A universal strategy is to create a development process that detects and repairs defects early and systemically regardless of project size.  The practices used within the software delivery lifecycle are under control of the team and these are extremely influential in cost and drama of delivery.  Defects introduced early in the SDLC are more expensive to fix than defects introduced later or discovered quickly.

Every stage of the SDLC introduces defects:

• design
• implementation
• deployment
• operations

Examples of potentially Expensive Defects:

• designing a database schema that eliminates the possibility of horizontal scaling
• using a relational database as a high concurrency message queue
• failing to validate or sanitize input data properly resulting in broken data or security breaches
• using a language’s concurrency features incorrectly
• changing API or data model semantics

Defect Detection Methods by Stage of SDLC

Use at least one method for detecting defects in each stage of the software delivery lifecycle so they can repaired before escaping to the next stage.   When a defect escapes to the next stage, it causes a larger impact to the organization and project costs.  Tailor the quality delivery plan to manage the risks of the project and the strengths of the team.  No one defect detection method is capable of detecting all defects before production or improving productivity throughout the SDLC.  Select and use many detection methods to detect (and then repair!) enough defects to deliver the quality expected by customers.

Defect Detection Plan

The following table shows how a defect defection plan using common 6 quality methods detects

• defects in each stage of delivery, reducing internal drama and costs
• more than 90% of defects before delivery to production

Do you have a robust process for detecting and eliminating defects from your software delivery pipeline?

Launch your own defect-detection spreadsheet and determine the percentage of defects your SDLC allows to escape to production!  We will explain more about the defect detection plan and how to use it in an upcoming blogpost.  For now, it is enough to use the worksheet to identify SDLC stages where defect detection is missing and characterize the impact to software delivery.

Summary

Delivering software on-time with acceptable (or exceptional!) quality is achievable with a good plan.  Decompose the system and use defect detection methods in every stage to keep problems to a manageable size and easily-discoverable.

---

References

• The Economics of Software Quality (Jones & Bonsignour)
• Defect detection rate data: Code Complete (McConnell)

---

If you would like any help understanding or applying these practices within your organization, please contact us — we’d love to help!