Typical Clan Kitty day schedule:

Up at 6AM.

Hector Kitten through her morning routine.

SpouseKitty waits with Kitten for the schoolbus, so they're out the door by 7:15.

I sometimes leave with them, when I'm trying to be on the ball. Sometimes I leave a little later. Rarely, though it's known to happen, I don't leave until 9AM. It's nice to have a job without a timeclock, just a never-ending series of Damoclean deadlines.

Lunch is when I take it. Cafeteria is open from 7AM to 6:30PM, though it's only salad bar and grill outside the main 11AM to 2PM lunch rush. Each clump of buildings has its own cafeteria. They've decent food at very good prices.

Imagine that. If you run your cafeteria at a loss (I'm guessing) with good food, your employees will stick around work. Less time in transit, more face-time talking about work matters.

During the lunch rush, my cafeteria has burritos to order, sandwiches to order, a sort of 'point at the veggies and protein and the cook will grab some for your pasta or rice' cook-to-order, salad bar, pizza / calzone / carb-oteria, and, of course, the grill.

At least once a week, I hit the grill for dinner, too. This past week, I've not been leaving work until at least 8:30PM. Yes, that's 13 hour days on average. 65 hour weeks. It's not that I love my job.

Don't get me wrong: I'm honoured to work there, am elated I have a job with them, find my work challenging. But I don't love it -- there's just too much frustration, both with what I have to do what I need to do, and with my own disconnect between what I know in theory and how I execute in practice.

The past week was fighting to get a bunch of machines ready so I could test the system of software. More and more software is "software as a service," as opposed to something that sits on your box. This blog is a service. Webmail is a service.

(Even a web server is a service, but it's scraping bottom. A service is usually something that stores data for you, not just pushes it out to you.)

The problem with testing a service is that it's not just a single component. Even testing a single component can take much drain bamage. A service is weaker than the strength of its parts. If components fail to work together, each may be correct and stable, but the service could go south nonetheless.

Testing a service starts with testing the components, but then requires navigation outward through many layers until it's "what the user sees."

Anyhow, the past month I was supposed to be studying the system to determine how to test it. I've only just gotten the system up and running in order to study it. I'm doing the exact wrong thing: I'm testing as I go.

The pseudo-scientific way of saying this is "ad hoc," as in "ad hockery." This is a good way to miss large areas because I'm missing the overall map. However, I don't have a choice. My deadline is in a week and a half.

Of course, I can point out that the development team's deadline was a week ago and they're still making changes, but that's a fact of life. Deadlines are guidelines, but they should be strong ones.

The stuff I find in test falls into three large categories:

1. Stop-ship. This sort of bug pulls the emergency brake. It can't go out like this.
   
2. Put in release notes. This would be the stuff you have to worry about, work around. "Doctor, it hurts when I do this." "Well, don't do this."
   
3. Punt. Don't worry about it. It's not that no one will see it, it's either that few enough people will, or it's minor enough, that we can wait to fix it next release. Or the one after.

Fact of life with any piece of software, folks. It's not just my company. Every software company, every development team (even if they're not selling the software, but making for another group in the company), every coder knows this.

"There's not enough time to do it right. There is enough time to do it over."