ENGINEERING APPROACH
Give the work a structure.
The Broken Pickaxe engineering approach organizes work into six connected phases.
Understand. Design. Build. Verify. Deliver. Improve.
The phases provide direction without pretending that development moves in a perfect line. New information can send the work backward when a decision needs to be reconsidered.
01 / UNDERSTAND
Know what needs to be accomplished.
Understanding establishes the problem and the intended result. It identifies the people affected by the solution and the constraints around it. Existing systems and processes can also influence what is possible.
Useful evidence may include requirements and user needs. Constraints and acceptance criteria make the expected result clearer before technical decisions accumulate.
02 / DESIGN
Decide how the pieces should work together.
Design gives the product structure. Responsibilities can be separated and important relationships can be defined. Security and operational needs can influence the architecture while meaningful choices remain open.
Useful evidence may include architecture and data design. Interface decisions and security considerations explain why the system takes a particular shape.
03 / BUILD
Turn the design into working software.
Build turns requirements and design decisions into something that can be used and tested. Small increments make it possible to check the work before the entire product exists.
Source code and configuration are part of the evidence. Automated checks can handle routine validation while the implementation remains connected to its purpose.
04 / VERIFY
Check the work before trusting it.
Working software is not the same as verified software. Verification tests behavior and the qualities expected from the product.
A failed check is useful information. A coding problem can return to Build. A flawed assumption may require another look at Design or Understand.
Evidence can include focused tests and browser journeys. Accessibility checks and security checks address different risks and should be interpreted within their limits.
05 / DELIVER
Move a verified result into use.
Delivery should preserve the controls that supported development. Configuration and deployment behavior need to match the environment where the software will operate.
The amount of delivery engineering should fit the product. Runtime checks and useful operational documentation provide evidence that the intended application reached the intended environment.
06 / IMPROVE
Use what the work taught us.
Implementation and verification create information that did not exist at the beginning. Useful lessons should influence what happens next.
The product can improve and so can the practices used to build it.
FIT THE PROCESS TO THE WORK
Discipline does not require unnecessary ceremony.
A small project does not need the same engineering weight as a complex application. The lifecycle can stay recognizable while the depth of each phase changes.
The important controls should match the risk and complexity of the work.
TRACEABILITY
Connect the result to the reason it exists.
A requirement can explain why a capability exists. An architecture decision can explain why the system was structured a certain way. Verification can show whether the expected result was achieved.
NEED → REQUIREMENT → DECISION → IMPLEMENTATION → VERIFICATION
Preserve enough context that important decisions do not become mysteries later.
CONTROLLED EXECUTION
Put judgment where judgment belongs.
Routine technical checks can be automated. Product choices and security decisions remain human responsibilities. Consequential changes need deliberate review by the people accountable for the result.
Build. Verify. Learn. Improve.
A structured lifecycle does not eliminate uncertainty. It gives the work a way to respond to it.
Next: Secure Development