so there we were… watching the system running. we were on the phone, both tailing the app server log file (tail -f ... ) to watch some progress via the age-old, tried and true, logging statements.

the app is doing a lot… running through more than one data source, dynamically generating sql based on meta data and an ontology, dumping it to a triplestore, running rules (invoking some gnarly stuff), culminating in a report.

it was streaming past at a good clip, then you could see it bog down at one point where there was an especially nasty bit of stuff going down for accomplishing a bunch of rule stuff. Then it began moving again at a good clip. There was definitely a visible “rhythm” just watching each part of the system crank through the dozen or so “sections.”

“I’m pretty sure that is where it is doing the ‘saveToStore()’ call.” I thought it was instrumented with some logging… Hmmm. “Wait a minute” my friend said. “Those rule forms… we don’t need to put any of that info into the triplestore since we aren’t displaying any of that info. The triplestore is merely for running SPARQL queries against to get the info out to the browser.”

“Good point!” I said. So he added one line of code to disable calling saveToStore in the case of no SPARQL being specified. That single change resulted in reducing the time by 70%.

Funny what can happen when a couple of people are almost casually talking through and re-thinking the system behavior. thanks lb

sometimes, in challenging development projects, some of the solutions are out there… you can see them through the mist, or the rolling fog. you know intuitively what the solution should look like. but the implementation can be tricky.

it is worth pushing onward, through the fog, trying to burn it off.

why? because in all likelihood, it is the hard bits of an innovative project that really provide the value to the client.

Just listened to a wonderful keynote by Timothy Lister at GLSEC conference.. A man after my own heart with his ability to say the things many people don’t want to hear about software projects.

This was the first quote I jotted down:

Estimate software projects by the season

It came from his mathemetician father who was reviewing some stats that Tim and Tom DeMarco had gathered on initial estimates for software projects and actual results. His father summarized the granularity of estimates could not be any finer than seasonal!

Brilliant!

I was doing tech support for a good friend… seems an email message in Outlook Express would cause the app to freeze. Move to it, and BAM. So, deleting it outright was out of the question. Even archiving the email would cause it to freeze. Mind you, other messages from this sender were fine.

So I thought of a clever way. I created a rule for the sender and the subject, and selected the action to delete the message. Told the app to execute the rule. Guess what? Yeah, it froze again. With the blank outline of the rule execution progress dialog up in all its blank-stare glory.

My response as a professional software person? Besides embarrassment for our entire industry, I said “I don’t think I could code this as a feature if I had to.” (Of course, we all know we could do something clever like “If message number 10959 arrives, freeze app’s UI message handler.”

So, could you code this behavior? Have you ever found yourself expressing such wonderment at amazingly bizarre program behavior?

I am enjoying working on my new MacBookPro after nothing but windows machines, a half dozen dell laptops, etc.

What is really cool, besides stuff just working, is the ease with which I can do development work. The Mac OSX makes it seamless to switch back and forth with the linux server. Most useful!

Getting back on the windows laptop is still familiar territory, but I already find my fingers in the wrong places.

Yeah, the Mac’s weirdness surrounding Control, Option, and Command modifier keys, could stand to have someone bonked on the head with a rubber mallet .

A good friend of mine, Chris Lank, from TogetherSoft days, is now the CEO of Ivis, proud creators of xProcess. He’s piqued my interest lately (well, not *that* way)!

This looks very much along the lines of a process/workflow dream/vision i have held for years (and implemented independently from them to a beta stage). Ever since working on developing IBM’s (as of 1995) next-gen Manufacturing Execution System, ideas have swirled around how to break the log-jam of classic project management solutions for processes that don’t lend themselves well to simple Gantt charts.

I’ll have to poke around more on their site and talk to my old TS pals that are there. This tutorial looks like a good start…

The GLSEC is being held in Grand Rapids, MI, on 25 & 26th October.

I am scheduled to deliver a talk on “Pragmatic Agile Model-Driven Architecture.”

Carl Erickson figures it just has to be an oxymoron!

As many of you may have guessed, I decided to go off and do my own thing. Compuware was fun and I really enjoyed the folks I got to work with on a daily basis.

So now i will work to help teams be more pragmatic; consult on architecture, work with project teams, help with implementation, mentor on lightweight development processes, etc. Basically, figure out the next thing i want to be when i grow up ;=) I even have a novel that i want to write!

My blogs from the past year can still be found here

I’m going to resume blogging, thanks for your patience ;=)

— jon kern

ps: thanks to the little butterfly that kept waiting for my next blog entry