Re: Newbie question on table design.

David Cressey wrote:
> ...
> Fair enough. IBM culture was big enough, at the time, so it could
> accommodate a large number of internal subcultures. The part of IBM culture
> that was visible to me was definitely not into interactive development.
>
> Even though they had interactive terminals, on line editing, etc. etc.
> compiling a source program was a batch job. And that affected the workflow.
> ...

Nit: I think this should have said "typical" IBM culture. I once worked in an atypical IBM shop where, for example, very few programmers knew any JCL, that included assembler programmers. Nearly everybody used TSO and TSOTEST exclusively for compiles and assemblies, so-called "link-edits" and debugging. There was no waiting for batch jobs to start. Typical IBM installations usually forbade this for cost reasons but a few bought enough hardware to allow it. I found it just as productive as using the early Borland "Turbo" integrated environments on a dedicated PC. Very few people needed to understand how to write tso "clist" scripts, just as very few Borland customers needed to modify the standard "workflow". One could expect several thousand lines to assemble and link with other code in as little as ten seconds and usually compiles too. One typically was dealing with several hundred thousand lines in any given component, but things were arranged so that usually only a handful of modules needed to re-compiled.

(Big service bureaus loved JCL because it tended to guarantee that most customer production jobs needed to be run at least twice and therefore paid twice!)

Admittedly, that was a one-product shop, where most developers worked only on a single layer of code that communicated with other layers via a very small number of strict interfaces, so little or no MVS knowledge was needed by most developers, ie., it was a highly-optimized environment. When typical assembler programmers were hard to find, it was a matter of days to hire bright people and teach them about twenty assembler instructions and a handful of service macros plus tsotest so they could debug. Sometimes I indulged in private mechanical productivity comparisons. For straight-forward and like work, I concluded that the greatest difference between developers was usually their typing speed and machine response was irrelevant. OTOH, the bigger differences between developers usually varied directly with how well they understood the product as compared to the environment and how carefully they practiced informal walk-throughs. Fifteen years later, I find the environmental knowledge needed to be productive with the integrated PC development languages to be mind-boggling in its complexity, eg., when I see some Java or SQL-server stack dump on a failed web site or the massive build scripts that so many open-source products have. When it comes to dbms's or any app, I suspect this severely impedes seeing the forest instead of the trees.

p Received on Fri May 04 2007 - 18:38:31 CEST