Cart
[Home] [By Thread] [By Date] [Recent Entries]
i think a better example than the airplane one discussed here, is the vibrating bridge that destoyed itself in high winds, or any of the amazing engineering feats in the recently shown tv series (brooklyn bridge, panama canal, etc). the reason i say this is that they all have the elements that are important - money, politics, disaster, engineering (somewhere). but most importantly the results of the successes and failures all fed into the engineering education systems and are passed on by the institutions to each new generation of engineers. learning by magazine or experience (or even a few good books) will never replace the disciplined study of a formal education at the university of technical level. mainly because those who design the courses (hopefully) make sure that your education is broad and covers areas that you wouldn't normally follow if you just pursued your interests. the challenge remains to develop and maintain software engineering and computer science courses that do the same (i know there's lots out there, i've been through the system) and the incentive for young prospective software people to undertake them. maybe professional licencing and liability would be a good idea. my own experience is that it can be difficult to introduce programmers to xml technologies because they see it as yet another language to learn and they're happy with what they've got. without suitable education on their part it can be difficult to find a common language to explain the benefits and other reasons for our approach. the same problems exist in the rdbms world and even in the c world. rick Michael Champion wrote: >On Sat, 01 Jan 2005 14:57:05 +0000, Bill de hÓra ><bill.dehora@p...> wrote: > > > >>On the other hand trying to delineate what's engineering and what's >>alchemy in a software sense is no bad thing >> >> > >I'm not sure I follow. To me, it's not clear what is alchemy and what >is engineering and what is computer science in the real world. The >Cali plane crash example seems to illustrate that -- the on-board >software worked as designed, and the design was rational, it just made >assumptions about a) the distribution of navigation beacons and b) the >attention to detail on the part of the pilots that turned out to be >over-optimistic. Is this engineering or alchemy? I'm not sure. >Benjamin Franz seems to think that best practices are clear and a good >process could have caught these unrealistic assumptions in advance. >Maybe, but I have a feeling that "best practice" is more of a >collection of hard lessons learned from investigating disasters, and >anticipating new flaws at the design phase is more in the realm of >alchemy than engineering. But maybe this is just a matter of using >slippery and value laden words in inconsistent ways, not real >disagreement. > >But remember that Newton was an alchemist, and Kepler was an >astrologer :-) So, it probably is worth trying to delineate >engineering from alchemy, but I expect the line to be pretty fuzzy. > >----------------------------------------------------------------- >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an >initiative of OASIS <http://www.oasis-open.org> > >The list archives are at http://lists.xml.org/archives/xml-dev/ > >To subscribe or unsubscribe from this list use the subscription >manager: <http://www.oasis-open.org/mlmanage/index.php> > > > > begin:vcard fn:Rick Marshall n:Marshall;Rick email;internet:rjm@z... tel;cell:+61 411 287 530 x-mozilla-html:TRUE version:2.1 end:vcard
|
