Do The Right Things Before You Do The Things Right
Part 5 of 8 in the Prototype-First ECU Development series.
1. Overview
Many automotive programs are strong at doing things right.
They know how to create process compliance, architecture reviews, coding standards, traceability, verification plans, and release evidence. All of that matters.
But disciplined execution cannot rescue a program that is still converging on the wrong system boundary, the wrong interface assumptions, or the wrong architecture split.
That is why the sequence matters.
Before doing the things right, the program must first do the right things.
3. Two Different Kinds Of Work
In practice, modern ECU programs need two distinct modes of work.
3.1. DTRT: Do The Right Things
This is the discovery-oriented phase.
Its job is to reduce uncertainty around what the system should actually be:
-
which problem is really being solved,
-
which interfaces matter most,
-
which requirements are missing or overstated,
-
which design alternatives survive contact with reality,
-
and what later verification will need.
This phase is usually prototype-heavy because executable learning is the fastest way to challenge assumptions.
3.2. DTTR: Do The Things Right
This is the disciplined execution phase.
Its job is to formalize, harden, optimize, and verify what the earlier phase has made more credible:
-
stable requirements,
-
formal architecture,
-
traceable implementation,
-
product-grade code quality,
-
and structured verification and release evidence.
In short, DTRT reduces the risk of building the wrong system. DTTR reduces the risk of building the system poorly.
4. What DTRT Should Answer
The discovery phase should leave fewer foundational questions open.
By the end of DTRT, the program should be in a much better position to answer:
-
What is the real system boundary?
-
Which functions and use cases are central, and which are secondary?
-
Which interfaces are credible enough to commit?
-
Which architecture choices have already been challenged with evidence?
-
Which benches, tools, logging paths, and automation hooks are needed before formal verification intensifies?
If these questions remain largely open, the program is not ready for full DTTR.
5. What DTTR Must Deliver
Once enough uncertainty has been reduced, the formal phase must become intentionally heavier.
DTTR should deliver:
-
reviewable and better-stabilized requirements,
-
documented architecture with clear ownership and rationale,
-
robust traceability across requirements, design, code, and verification,
-
production-grade implementation quality,
-
and complete verification and validation discipline appropriate to the product context.
This is the phase in which maintainability, diagnosability, performance behavior, release readiness, and compliance evidence must become non-negotiable.
6. The Transition Gate Matters More Than The Label
The most important decision is not the vocabulary. It is the transition point.
If the program enters DTTR too early, it formalizes unstable understanding and pays later through rework. If it stays in DTRT too long, discovery becomes open-ended and schedule confidence weakens.
A sensible transition usually requires evidence that:
-
the biggest concept risks are understood,
-
key interfaces have been exercised,
-
the requirement baseline is materially stronger than it was at program start,
-
major architectural alternatives have been narrowed,
-
and the verification infrastructure path is visible.
I would make that transition gate explicit. If the exit criteria stay vague, the organization will eventually slide back into either premature formalization or endless exploration.
7. Failure Modes When The Sequence Breaks
8. Why This Framework Helps Automotive Programs
Automotive development is full of competing pressures: standards, sourcing, cost, schedules, supplier interfaces, platform reuse, and product quality. DTRT and DTTR help because they give those discussions a cleaner sequence.
The message is simple:
-
first earn confidence in what should be built,
-
then spend heavily on building it well.
That sequence protects rigor rather than weakening it.