2011-06-29

Artifacts

I have to fight to suppress a smile whenever I hear people talk about the "artifacts" that have to be produced as part of any modern systems development methodology.  As far as I can tell, the term "artifact" has replaced the more descriptive "deliverable", but that's not what I find amusing.

To me the word "artifact" has always meant something like: "An man-made object of historical or scientific value that has no practical use."  Or, in another sense, "data corruption produced by an error in the process that measures the data".  To those of us in the trenches who are required to create "artifacts" in addition to executable code, both of these definitions seem apt.

Ergonomic impact of full screen debugging tools

Speaking of RDz, as I was in my last post, full screen debugging tools can have an unexpected ergonomic impact, at least on my decrepit old frame.

When writing code, launching and monitoring batch jobs, or testing an online screen the old fashioned way, I tend to sit back in my chair in a fairly relaxed posture.  Debugging interactively, whether using RDz or another tool, tends to change that.  I lean forward in my chair intently focused on the screen in front of me as I watch the code execute.    I feel poised, ready to pounce when the next breakpoint comes up or when the execution flow appears to go awry.

All this is good fun (I love debugging), but it gets physically wearisome when you do it continuously for 8 hours or so.

Cruelty to Mainframers

Was IBM deliberately cruel to us old mainframers when they designed RDz?  Why else would they assign F8 to "Run until next breakpoint"?  I cannot tell you how many RDz debugging sessions I've ruined by hitting F8 in the source window when all I meant to do was scroll down.