Work
Engineering mission software at scale
Engineering mission software at scale
Hands-on engineering and technical delivery on a simulation program — roughly 20 repositories, three environments, a team of about 10, and partner and vendor teams. Six engineers onboarded and coached. A portable messaging layer is in use; ownership is shared.
Impact & evidence
~20 repositories · 3 environments · 6 engineers onboarded
Current program scope. Shared ownership; program-specific details are not public.
On this page
Problem
- Independently developed services need compatible interfaces and repeatable integration.
- Delivery conventions varied by repository, which made reviews, testing, and releases harder to trust.
- Work spans roughly 20 repositories, three environments, and multiple Jacobs, partner, and vendor teams.
Decisions
- Put CI/CD, two-approval review, testing, type-checking, security, coverage, and release practices on a shared baseline.
- Separate application messaging from the broker behind a common interface and adapters.
- Treat tests that do not exercise behavior, and late integration, as defects in the engineering system.
Engineering delivery system
Validation feedback
-
Local development
Code
Pre-commit
format · lint · imports · types · secrets
Commit / push
-
Repository validation
Pull request
Review
2+ approvals
CI pipeline
unit tests · coverage · SAST
dependency audit · build
Merge gate
review + CI pass
-
Change intelligence
Change detection
Delta tagging
Cross-repo impact
-
System validation
Integration tests E2E tests Environment validation Release
Evidence
- Engineers on the team
- ~10
- Repositories in scope
- ~20
- Repository test coverage
- ≥80%
- Adopted Delivery gates
- Shared CI/CD, two-approval review, testing, type-checking, security, coverage, and release baseline in use across the repositories in scope.
- In use Portable messaging
- Common interface and broker adapters. Ownership is shared; every consumer is not claimed.
- In progress Unit-test standard
- Written and used in review. Not a repository-wide rewrite.
- Ongoing Cross-team delivery
- Tickets, sequencing, and coordination. Not a closed initiative.
- Shipped Coaching
- Six engineers onboarded. Personnel decisions remain with management.
Outcome
- Established at least 80% repository test coverage, two-approval pull-request governance, and automated quality gates across the repositories in scope. Releases are safer and more predictable.
- Shared delivery gates are the adopted baseline across those repositories.
- A portable messaging layer is in use so broker choice can stay in configuration. Ownership is shared.
- Stronger unit-test expectations are defined and applied in review. They are not a finished program-wide rewrite.
- Six engineers onboarded and coached while the same practices were reinforced in review.
Scope
- Owns
- Day-to-day software delivery, engineering standards, mentoring, and hands-on implementation across roughly 20 repositories.
- Influences
- Program priorities, vendor and partner-team dependencies, and integration across repositories.
- Reserved
- Staff individual-contributor role; formal personnel decisions remain with management.
Team & contribution
- Contribution
- Hands-on technical leadership
- Team & partners
- About 10 engineers, plus program stakeholders, partner teams, and vendors
- What I improved
- Onboarding, technical feedback, and turning integration problems into tickets while the change is still cheap.
- Key decision
- Treat weak tests and integration risk as engineering work, not process leftovers.
Formal personnel management remains with management.
Program-specific architecture and operational details are not included here.
Read the status labels as the adoption record: delivery gates are the baseline, messaging is in use with shared ownership, the unit-test standard is in review, and cross-team delivery is ongoing work.
A concrete defect: some tests reported coverage without failing when the behavior was wrong, including filters whose no-op path never triggered a failure. Remaining test work is quality — isolation, representative data, and failure cases on changed code — not another coverage number.
Delivery practices
A change is ready when another engineer can review it, rebuild it, and see the evidence. These expectations live in tests, CI, review, and coaching, not in a separate process checklist.
Definition of Done
- Purpose, scope, and ownership are clear.
- Tests cover changed behavior, including relevant failure cases.
- Required quality, packaging, dependency, and security checks pass.
- Interfaces and deployment assumptions have been checked, with remaining risks recorded.
- Versioning, release notes, and supporting documentation are ready for the next person.
Pull request rubric
Review for correctness at boundaries and failure cases, evidence that tests check meaningful behavior, maintainability of interfaces and error handling, and context for important decisions. Reviews should improve the change and help the author understand why.
Make integration risk visible
A working component is not a working release. Identify dependencies and interface assumptions before they block implementation, exercise integration paths throughout development, and record blockers, ownership, and the evidence needed to move forward. Keep changes small enough to test, explain, and recover.
Make the practices shared
Put repeatable checks into tooling rather than reminders. Explain the reasoning in reviews, include release expectations in onboarding, and adjust practices when they add work without improving delivery.