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.
On this page
- 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.
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.
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.
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
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.