IOSM: an Algorithmic Engineering Methodology you can automate
Source: Dev.to
Introduction
Most engineering teams don’t fail because they lack talent. They fail because improvements are chaotic:
- refactors without a finish line
- “performance work” without a baseline
- “modularization” that increases coupling
- endless polishing that never reaches business value
So I built IOSM — an algorithmic methodology (not a vibe, not a manifesto) that turns system improvement into an executable discipline: configuration, gates, metrics, and a health index you can drive in CI/CD. :contentReference[oaicite:0]{index=0}
IOSM stands for
Improve → Optimize → Shrink → Modularize
The key idea is brutal in its simplicity:
Metrics over opinions. Every step is validated by gates. :contentReference[oaicite:1]{index=1}
Vision
Predictable evolution instead of heroic refactors.
IOSM is designed to eliminate chaos in improvements, reduce cost of change, increase predictability, and align engineering with business value. :contentReference[oaicite:2]{index=2}
The intended outcome is systems that become clear, fast, simple, and scalable. :contentReference[oaicite:3]{index=3}
That’s not a slogan — it’s enforced.
Axioms (the “why” behind the algorithm)
IOSM is built on a few non‑negotiables:
- Clarity is a prerequisite for speed (unclear architecture kills velocity)
- Efficiency = performance × resilience
- Simplicity reduces risks and costs
- Modularity is the engine of evolution
- Economics of change drives prioritization
- Feedback closure: improvements must be validated by business + user feedback :contentReference[oaicite:4]{index=4}
If your process contradicts these, IOSM will keep pulling you back toward them.
IOSM as “Configuration‑as‑Code”
Here’s the part most methodologies miss: you can encode IOSM.
A minimal iosm.yaml can define what “good” means for your system:
# iosm.yaml
gates:
improve:
semanticClarity: true
logicalConsistency: true
duplicationLimit: 5
optimize:
latencyTargetMs: 100
errorBudgetPct: 99.9
chaosTesting: true
shrink:
apiSurfaceReductionPct: 20
onboardingTimeSec: 30
modularize:
changeSurfaceLimit: 10
contractPass: true
weights:
improve: 0.25
optimize: 0.25
shrink: 0.25
modularize: 0.25- Weights for a composite IOSM‑Index :contentReference[oaicite:5]{index=5}
This is the shift: instead of “we should clean it up,” you get quality gates that fail a build.
Core: an orchestrator, not a checklist
IOSM is explicitly defined as a cycle orchestrator:
- Pull backlog items
Prioritize by economic decision - Run phases in order
Advance only if the gate passes - Collect metrics and compute an IOSM‑Index
- Decide whether to continue or stop :contentReference[oaicite:6]{index=6}
That “advance only if gate passes” rule is where the discipline comes from.
The four phases (what you actually do)
1) Improve — make the system understandable
Unclear systems create fake speed and real pain later. The Improve phase includes:
- build a glossary
- enforce naming conventions
- remove duplication
- define invariants and instrument assertions :contentReference[oaicite:7]{index=7}
Gate‑I is your “we can reason about this now” checkpoint.
2) Optimize — make it fast and resilient, but only with a baseline
Optimization without a baseline is a classic self‑own, so IOSM bakes in:
- profiling → bottleneck identification
- targeted optimizations
- resilience patterns
- chaos tests + benchmarks :contentReference[oaicite:8]{index=8}
This is performance work that can survive a postmortem.
3) Shrink — reduce the surface area (where bugs and cost live)
Shrinking is about removing what you don’t want to maintain:
- find redundant APIs
- remove/merge them
- remove unused dependencies
- measure onboarding time :contentReference[oaicite:9]{index=9}
This phase is where “complexity budget” becomes real.
4) Modularize — restructure so change is contained
Finally, you earn modularity:
- build a dependency graph
- partition it
- refactor to partitions
- define contracts + contract tests :contentReference[oaicite:10]{index=10}
Modularity isn’t “more modules.” It’s lower coupling + higher cohesion + smaller change surface.
Fitness functions: make architecture testable
IOSM encourages fitness functions — automated assertions that enforce properties like:
- bundle size limits
- layering rules (e.g. no UI → data edges)
- stable interfaces (no breaking changes) :contentReference[oaicite:11]{index=11}
This is how “architecture” stops being a PDF and becomes an executable standard.
Anti‑patterns IOSM is designed to catch
If any of these sound familiar, IOSM was made for you:
- selective phase execution (skipping phases breaks integrity)
- optimization without a baseline
- modularity for the sake of modularity
- endless Improve cycles
- shrink that breaks contracts
- micro‑optimizations at the expense of DX :contentReference[oaicite:12]{index=12}
How to adopt IOSM without boiling the ocean
Adoption roadmap:
- 0–2 weeks: Gate‑I / Gate‑S
- 30–60 days: Gate‑O / Gate‑M
- 90 days: stabilize at IOSM‑Index ≥ 0.98 :contentReference[oaicite:13]{index=13}
It also scales hierarchically: run cycles on modules, services, and whole portfolios, and benchmark the IOSM‑Index across systems. :contentReference[oaicite:14]{index=14}
The point
IOSM is not “a better way to refactor.”
It’s a way to turn improvement into a reproducible algorithm: configured, gated, measurable, automatable — so your systems evolve predictably instead of depending on heroics. :contentReference[oaicite:15]{index=15}
If you’re building platforms, large applications, or anything that must survive years of change, this is the discipline I wish we all had by default.
If you want to discuss / collaborate
I’d love feedback from teams who’ve tried to make architecture enforceable in CI/CD:
- What gates would you add first?
- What metrics do you trust?
- Where does your org get stuck: Improve, Optimize, Shrink, or Modularize?
(And if you want, I can share a concrete “starter template” iosm.yaml + example fitness functions for a typical backend service / monorepo.)
GitHub: