Charles Hayes

I've been working with Java almost since it existed. I first saw it as a book on an engineer's desk while I was an electronics test technician at Spectra Logic in Boulder, Colorado, teaching myself C on the side. Sun Microsystems had a campus eight miles from my home, and I decided I was going to work there. A few years of self-study and one lucky introduction later, I did: my first professional software job was building Java-based enterprise web applications at Sun.

Since then I've worked on enterprise Java systems from several sides: as a developer, as a test automation architect, and as part of a DevOps architecture team helping an organization move from waterfall delivery to continuous delivery. I've built and tested microservices, containerized test environments with Docker and Kubernetes, and set up the CI/CD pipelines that let teams change large systems without fear.

That mix shapes how I approach modernization. Most legacy applications aren't failing because of Java. They're hard to change because boundaries have eroded, tests are thin, deployments are risky, and knowledge is spread across a handful of people. Rewriting from scratch rarely fixes any of that. It usually just moves the risk somewhere you can't see it.

I treat modernization as a risk-management problem first and an architecture problem second. Microservices can be the right answer, but only when the domain, the team structure, and the operational maturity support them. Often the better first move is a well-structured modular monolith on a current Java and framework version, with tests and observability in place. From there, services can be extracted one at a time, behind a facade, with a rollback path at every step.

My background in quality engineering is a big part of what I bring. Characterization tests, contract tests, parallel runs, and good telemetry are what turn a high-stakes migration into a series of small, boring, reversible changes. Boring is the goal.