ENGINEERING APPROACH
Give the work a structure.
An idea becomes easier to build when the problem and expectations are clear. The Broken Pickaxe engineering approach organizes that work into six connected phases.
Understand. Design. Build. Verify. Deliver. Improve.
The phases provide direction without assuming every decision will be correct the first time. Findings can send the work backward when something needs to be reconsidered.
01 / UNDERSTAND
Know what needs to be accomplished.
Development should not begin with assumptions about what someone needs.
Understanding establishes the problem and the intended result. It identifies the people affected by the solution and the constraints surrounding it. Existing systems or processes can also influence what is possible.
The result is a clearer definition of the work before technical decisions begin to accumulate.
Questions: What problem are we solving? Who needs the result? What does it need to accomplish? What constraints matter? How will we know the result is useful?
Evidence: Requirements · User needs · Constraints · Acceptance criteria · Existing-system analysis
02 / DESIGN
Decide how the pieces should work together.
Once the need is understood, the solution can take shape.
Design establishes the structure behind the product. Responsibilities can be separated and important relationships can be defined. Security and operational concerns can influence the architecture while meaningful choices are still open.
The objective is not to predict every implementation detail. It is to make the decisions that give construction a sound direction.
Evidence: Architecture · Data design · Interface decisions · Security considerations · Decision records
03 / BUILD
Turn the design into working software.
Construction turns requirements and design decisions into something that can be used and tested.
The work can be divided into controlled increments instead of waiting for the entire product to exist before checking it. Implementation stays connected to the decisions that established its direction.
Automation can handle repeatable work when the expected behavior and boundaries are clear.
Evidence: Source code · Configuration · Build results · Implementation records · Automated checks
04 / VERIFY
Check the work before trusting it.
Working software is not the same as verified software.
Verification tests the behavior and qualities expected from the product. A failed check is information. It identifies something that needs investigation rather than something that should be hidden to preserve forward motion.
When evidence reveals a defect, the work returns to the appropriate phase. A coding problem might return to Build. A flawed assumption could require another look at Design or Understand.
Evidence: Automated tests · Browser tests · Accessibility checks · Security checks · Regression results
05 / DELIVER
Move a verified result into use.
Delivery is more than transferring files to another environment.
The product should reach its intended destination without discarding 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. A small website and a business-critical application do not require identical operational systems.
Evidence: Release records · Deployment validation · Runtime checks · Configuration evidence · Operational documentation
06 / IMPROVE
Use what the work taught us.
A completed piece of work creates information that did not exist at the beginning.
Testing can reveal weak assumptions. Implementation can expose unnecessary complexity. Delivery can identify gaps in the process itself.
Useful lessons should influence what happens next. The product can improve and the engineering system behind it can improve too.
Evidence: Lessons learned · Improvement actions · Product backlog · Process changes · Updated engineering guidance
Primary path: UNDERSTAND → DESIGN → BUILD ⇄ VERIFY → DELIVER → IMPROVE
Verification can send work backward. Improvement feeds learning into future work.
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 remain recognizable while the depth of each phase changes.
A straightforward site might need concise requirements and a simple architecture. A larger system may require deeper analysis and more extensive verification.
The important controls should match the risk and complexity of the work.
TRACEABILITY
Connect the result to the reason it exists.
Engineering becomes easier to defend when important decisions can be traced back to a purpose.
A requirement can explain why a capability exists. An architecture decision can explain why the system was structured a certain way. Verification can provide evidence that the expected result was actually achieved.
NEED → REQUIREMENT → DECISION → IMPLEMENTATION → VERIFICATION
Not every project needs a complicated traceability system. Preserve enough context that important decisions do not become mysteries later.
CONTROLLED EXECUTION
Put judgment where judgment belongs.
Some engineering work is mechanical. Tests need to run. Known validation failures need correction. Files need to be checked against expected boundaries.
Those tasks can move quickly when the expected work is already defined.
Other decisions change the product or the authority behind it. Those decisions should remain deliberate.
Routine work can proceed inside defined boundaries. Unexpected or consequential conditions return control to the appropriate decision maker.
Build. Verify. Learn. Improve.
A structured lifecycle does not eliminate uncertainty. It gives the work a way to respond to it.
Next: Secure Development