I build software in small, tested steps and ship each one to production as soon as it is ready. I've refined this way of working over my career and wrote it up as a book, CASE: Continuous Agile Software Engineering. This page shows what it looks like in practice, and the results it has produced.

Ship small, ship often

Every change is small enough to review, test, and release on its own, so problems are found while they are still small, and users get improvements as soon as they exist.

• At General Services Corp, I pushed to production several times a day. The reporting portal I built went live with its first reports in its first week of development, then grew to hundreds of reports.
• On Fabric Engine, I ship engine features and optimizations in hours or days, not in large batches.
• On my own sites, every push to main deploys, so a fix goes live as soon as its tests pass.

Let tests decide what ships

Shipping often only works if each release is safe, so the checks are automated and run every time.

• Every deploy of my sites runs its Playwright tests first, and a failing test stops the deploy.
• The Web UI framework can't add a component or method without tests, because a coverage test fails until they exist. See the Web UI case study.
• Fabric Engine validates every shader in cargo test, so a shader error fails the build instead of the running game.

Measure performance, and treat slowness as a bug

Speed is a feature users notice first, so I set a standard and hold to it.

• At General Services Corp, every browser-to-server request had to finish in under 100 ms, and anything over 300 ms was treated as an urgent bug, across hundreds of reports.
• At Microsoft, I prototyped and partly built a re-architecture of a customer-facing reporting service, bringing queries that took from tens of seconds up to hundreds of minutes down to between milliseconds and a few seconds.

Keep it simple

The simplest thing that delivers value is usually the easiest to change later. In practice that means removing boilerplate instead of copying it: a layout used in more than one place becomes one shared component, and unused code is deleted rather than kept "just in case".

Grow the team, not just the code

• At Microsoft, I ran training sessions on unit testing and test-driven development, and mentored a new graduate engineer who went on to become the team's UI lead.
• At SoftRock, I moved the team toward object-oriented code and consistent best practices, and within six months of first learning ColdFusion I was teaching new parts of the language to experienced ColdFusion developers.

Erik is an out of the box thinker and a great collaborator.

Learn more

The twelve tenets of CASE The CASE book SoftwareStandards.dev