Why I built a tool for DBAs instead of just running the queries individually

Almost every reporting problem a DBA has starts the same way: a query someone wrote once, saved in a folder, and now runs slightly differently depending on who opens it and which server they're pointed at. It works, until it doesn't — and nobody remembers why the WHERE clause has that one weird exception in it.

Scripts don't scale, even when they're good

A one-off script is fast to write and fast to trust — right up until it needs to run against ten servers instead of one, or a teammate needs to run it without a half-hour explanation first. The moment a query needs to be shared, repeated, or trusted by someone other than its author, it stops being a script and starts needing to be a tool.

What "tool" actually means here

To me, turning a script into a tool means a few concrete things:

• It runs the same way for everyone, every time — no editing variables at the top of a .sql file.
• It's safe to hand to someone less familiar with the environment.
• It doesn't require special access or installation on the server being reported on.
• Its output is consistent enough to compare across runs.

That last point is the one that led directly to SQLTempo — a report is far more useful when you can compare it to last month's report, not just read it in isolation.

Boring is a feature

The best tools I've built are the ones nobody notices, because they just work the same way every time. That's the bar I hold new tools to now: could someone who's never met me run this successfully, on the first try, without asking a question?

If a tool needs a training session to use safely, it isn't finished yet.

Where this is headed

SQLTempo is the current expression of that philosophy, and it won't be the last. Future posts will dig into specific report sections, real deployment scenarios, and the shift from static tooling to a full ASP.NET application as this project grows.