Here's a statistic: 99 percent of all achievements in computer science come from men. But, hey, I'm no statistician, so maybe I'll just trust some off-the-cuff twaddle from random jerks.
I try to show them how to properly graph a run chart and they're indignant.
Just wondering: Is this guy hacking device drivers? OpenGl? Maybe he's tweaking the last bit of sweat out of microsoft's C++ compiler? No...he's clearly doing CRUD work. Performance issues in CRUD work are solved by RAM and memcached, not screwing around in Excel. That's why your co-workers are indignant: You don't understand your trade.
If we want to only verify one single query on a database then what's stopping us? Stupidity that's what.
Because there are 6000 queries, and not all of us can spend all-day-all-night screwing around with Excel.
The classic example of this is the Pet Store
"The Pet Store" isn't the classic example of jack.
Then I hit the DB2 database and about crapped my pants. Almost all of the queries performed great, except one query that had sub-second response on average, but a 60 second standard deviation!
...my own statistics are a little rusty. If the average is .5, and the SD is 60, doesn't that mean that certain runs should be choking so hard that the log file would...just freeze. I mean, break out the Excel if you want, but I've seen log files choke before, and it's usually obvious what the problem is: The entry at the bottom.
"It's not the database, it's IBM's DB2 configuration.
LOL. DB2's configuration being a part of...what then?
The next day we had IBM fixing the problem (turned out to be a single update index command) and we all kept our jobs.
Our hero! (Self-proclaimed)
That's what a proper analysis method can do for you.
Or just watching the log file.