An occasional sampling of reader electron-mail, or "keep those waves and particles pouring in, folks!"
Thomas E. Momeyer, of Momeyer Associates in Peterborough, New Hampshire, writes:
> "There are frequent occasions when I receive the newsletter and select one of
the stories and it doesn't "load"... the blue progress bar moves slowly and doesn't seem to want to finish loading. I usually give up after a couple of tries…"
> The site speed problem has been fixed, and we apologize to all who were inconvenienced by this temporary glitch (and we thank all who were patient throughout these technical difficulties). Digitally adept readers will note that this site is posted using PHP, the Hypertext Pre-Processor, which compiles pages from their constituent text and graphics components. Our hosting service prominently proclaims that all its hosting packages include PHP4 and Zend Optimizer, which enhances the running speed of PHP applications. Our initial queries to the host service's technical support folks elicited the usual "your scripts are lousy, rebuild your entire site and rethink your entire business strategy" kind of response. Only upon repeated inquiries did we finally get a techie who conceded, "I am going ahead and installing Zend Optimizer onto your server—we have this installed on most servers, but looks like it was never installed on yours." This seems to have solved the problem, but it is disappointing that a feature promised on every hosting package "was never installed" on ours. The take-away lesson here is to always verify that all terms and deliverables in any e-business transaction are actually being fulfilled as promised.
Speaking of "verifying," our recent story, " Stupid Publisher Tricks: My So-Called (Digital) Life," on the dangers of unverified technology run amok, struck a responsive chord with a few readers. Prashant Telang, of Mumbai, India, co-founder of a software development outsourcing company and one of the largest pan-Asian AEC portals, writes:
> "I read your extremely well written article… I fully and completely agree with the premise: trust, but verify. Here in this part of the world we have been told that the WTC disaster could have been avoided if American intelligence would not have solely relied on technology, or rather over-relied on technology for info gathering. Human intelligence needs to be parallely processed."
> A sobering thought, indeed. We prefer to keep political discussion to a minimum in this forum, opting to focus instead on the intersection of design business and digital technology. However, even the possibility that the world's most sophisticated developers and consumers of technology might suffer the effects of over-reliance on their digital tools should serve as a cautionary data point to us everyday folk.
On the same topic, Jeremy Edmunds, an extremely well-qualified nominee for the National Associate Director position representing AIA/New York State, writes:
> "Great (even if a bit scary) article on credit cards & errant computer analysis in your last letter."
> As the world moves toward ever more tightly integrated, inter-communicating systems, the danger of propagating small errors into large problems will increase. This technological fact of life should not be taken as an argument against parametric design software or web-centric construction administration, but as a call to ensure that such systems retain the capacity for intelligent human intervention or overrides.
IssueEight's Laiserin'sLemma, "Ramblin' Wrecks Go Up the Down Staircase," Ed Anderson, of Pensacola, Florida sent a fascinating case summary which we reprint below with only slight edits for length. By his own admission, Ed finesses the question of the applicability of plant/process industry experience to AEC projects; I will be addressing the opposite question—applicability of lessons learned in AEC project collaboration to plant/process projects—in my October 30, 2002 talk at AspenWorld in Washington, DC (see also the LaiserinLive pages). Herewith, Ed Anderson's comments:
> "One company has identified an effective business model based on the premise that the owners and clients of buildings are the beneficiaries and should financially support this IT transition. Let me briefly describe it. In the following case we are talking about a chemical process facility as opposed to a building, but the principle, in my opinion, is the same, and the process can be used for either system.
"The company is Air Products & Chemicals, Inc. I am a former employee and we implemented the following when I was with them under the PALADIN program (Project Application Leveraging and Data Integration) starting back in 1993.
"The business premise was this: purchase and implement as much of an IT solution as would have a positive and reasonable payout on a capital project, such that both the new IT tools as well as the information asset that were created with the new tools could be passed on to the owner organization. For instance, one such tool was 3D CAD. The entire system was purchased and installed using capital funds, as is proper (no funny accounting deals here) on capital projects. Because the 3D CAD and the new work practices we created paid for themselves as part of the capital project, the hardware became available for downstream operations and maintenance activities at no additional cost to operations and maintenance.
"There are, of course, some little secrets to this that I sell as part of my new tech services business, but the basic business case is stated above and works…"
Fascinating stuff, and clearly applicable to large, repeat projects for or within the same client organization. Anybody else have experience with capitalizing the cost of digital tools to make them effectively free on subsequent projects?