Case Study
Coaching an agency's developers through a database crunch
A crisis call, then a half-day onsite teaching a Rails shop's own team how to keep MySQL fast.
Sometimes the most useful thing I can do isn't fix your code. It's make your team better at fixing it themselves.
The company
A Cambridge software shop that builds custom Rails systems for mission-driven clients — nonprofits and government. Good developers, real products in production. They'd hit a database performance wall and wanted an outside specialist to help, but they weren't looking for someone to take over their codebase. They wanted to get better at the thing that was hurting them.
What I did
It started in a crunch. We got on the phone while they were mid-crisis, and I gave on-the-spot MySQL tuning guidance — moving away from varchar(255) everywhere, archiving old data, breaking work into smaller transactions, and pointing them at the New Relic instrumentation they already had but weren't fully using.
The scope moved around a few times after that — they were candid that they were "all over the place" — and we landed somewhere better than the original plan. Instead of a formal written schema review, we did a roughly four-hour onsite presentation to their developers: conference-style, taking questions, tailored to their actual situation. Schema design, indexing, data-type choices, archiving, transaction sizing, storage-engine trade-offs. The point was that they'd walk away able to spot the next problem before it became a crisis.