Transfer of Knowledge

Log Out | Topics | Search Moderators | Register | Edit Profile

Author Message Ralph Liebing, RA, CSI, CDT Senior Member Username: rliebing Post Number: 1348 Registered: 02-2003 Posted on Wednesday, October 17, 2012 - 11:08 am:    121017 TRANSFER OF KNOWLEDGE By Ralph Liebing, RA, CSI, CDT Cincinnati, OH One of the underlying concepts behind some of the more advanced computer software developed for the AEC market is that it captures skill and knowledge. Many of you may remember spending hours learning to hand letter and then your first one or two jobs you got (or didn't get) because of your lettering. CAD/D supplants that skill with software that creates beautifully "Leroyed" or "hand lettered" annotations. The knowledge it takes to select which note to use or to create the note in the first place is the next task. Office design standards and those provided by clients encode such knowledge, externalizing both the knowledge and the rule base by which it is applied so that it can be used by those with very little training. Some of you may remember one of the allures of "cut-n-paste" drafting was that a "drawing" could be assembled by a graphic arts technician instead of an experienced draftsman. I have found the research in this area very interesting, but have rarely seen useful applications. The basic rule of automation/computing is GIGO "garbage in; garbage out". A corollary I came up with 20 years ago is when you automate a mess, you get faster messes. In my experience, few architects are able to externalize a knowledge base to where it can be automated; there are too many pieces and too many rules. There is also a bias on the part of many architects that if and when you can automate design process or some aspect of the process (like writing specifications), that part is no longer "valid design." It's the same argument that many designers make about computers, "You can't design with a computer." The computer merely records the human devised concept and design. If you can externalize knowledge and rules, maybe design isn't magic after all. Architects will disappear-- humph! Don’t bet on it!! Experienced and properly trained project architects are n the best position to produce a good specification for the project. They should know the project inside and out, the visual quality and the technical functionality; even the parts that have not yet been drawn. Unfortunately, they have some of the same scheduling problems that all of us have--too much to do and too little time. Moreover, most of them are more oriented toward graphic information, not toward verbal information. They have little understanding of the forms and formats of specifications, and little inclination to learn. They are frequently only dimly aware of some of the fundamental concepts and are not sure what goes in and what stays out. When combined with scheduling problems, the product is frequently lacking. The Project Architect's response when caught is usually not to improve the specification, but to put more information on the Drawings (which sometimes is what caused the problem in the first place). So we help the Project Architect by automating the first part of the process by having a computer routine which will assemble a 1st draft of the specification. The success of this largely depends on how complete the Drawings are and how accurate the annotations are. Will the software be "knowledgeable" enough to know that Sheetrock, gyp board, gypsum wall board, and gypsum board are the same product? Does the Project Architect know that there is a difference between lightweight concrete and lightweight insulating concrete? Although encoding all of this into standard notes and specifications sounds good and can be efficient in a well run practice, I have observed that it hinders some of the transfer of knowledge between the "silver foxes" and the "young guns." There is an advantage to drawing and redrawing a standard base flashing detail at a parapet (even on a computer). I learned a lot about materials by copying a freehand sketch detail and then drawing it over and over. It's not the same to copy a whole block into a drawing. I have also learned a lot by editing the same section 2 or 3 times a year. The more we automate, the more we bypass this traditional learning method which is one of the fundamental building blocks of apprenticeship/internship. Experienced architects and specification writers have the responsibility, in my view, to transmit a range of information and knowledge. It is frustrating to have to transmit the same basic information over and over again without getting to a more sophisticated level, but it has to be done if the design profession is to survive. I don't believe that simply automating a task or a series of tasks is the answer. I recognize that there are immediate benefits, but I am leery of the long term consequences.”