Besides welding, my other favorite thing to do with metal is to melt it. I must have melted 100,000 cans, the results of which are littered about my basement in various forms. So I was particularly happy to come across The Metalcaster's Bible while browsing through the 671's (Metalworking & metal products) in the non-fiction section of my local library.
While a lot of the techniques are outside of the scope of a school shop (where I cast), it was exciting to learn about the history and variety of techniques in casting. There are so many techniques and variables. Everything from the type of casting: sand, die, plaster, shell, slush, permanent molds, investment, foamed plaster; to the materials and techniques: green sand, petro bond, parting dust, synthetic sand, skin dried, no-bake, cored molds, hand built, sprues & cutters, flasks, boards, and on and on. C. W. Ammen has tried to cram a couple hundred years of casting history into about 400 pages, and its a pretty interesting effort, though some have complained that its a hard book to read.
Personally, I enjoyed reading the book from cover to cover, but then I like picking up the odd fact and learning absolutely everything about a subject that I can (regardless of whether I'll ever use it or not). The organization is not that good, so the best way to read through this book is like the way you approach a swap meet, or shop at Sam's Club. You don't go to Sams Club looking for a particular item (like metal shelves), instead you go to Sam's Club and you wander the isle and if you see something you're interested in, then you grab it. I suppose if I owned a copy of the Metalcaster's Bible, I'd have to dog-ear or bookmark many interesting pages, but instead I've just mentally captured as much as I could, and copied a few interesting pages.
I came away from this book with a real sense that metalcasting and programming are two very similar fields. (Its just that metalcasting has had a couple hundred years to mature, though it still has its bumps.) Both fields have numerous technologies, components, tools, and different end products (casting a bronze sculpture is an entirely different skill than casting an engine block or turbine blade). Metal casting has even had its share of over-hyped technologies which were misused and maligned until it found its proper place in the industry (gee, does that sound familiar?). As Ammen says about the shell process:
When the sand shell system was first introduced into the foundry industry, it was taken by some as the panacea. Before it found its true place in the industry, it took a heavy toll not only in botched-up castings but in money.It is a good system when properly used and its limits are understood. The same problem exists with any system. Investment casting particularly by art bronze casters is another with definite limitations. I have seen some costly messes made by investment casters who will try to cast a life-size casting all in one piece in investment when the casting could have been done in French sand with not only a finer finish, but at half the time and cost. Use the right medium for the job at hand.
One basic area where software engineering lacks is in terminology. We just don't have that many terms to describe the things we work with day in and day out. In comparison this casting book was 150 pages of content, and 225 pages of terms. It could have been called the Metalcaster's Dictionary. For example for sand casting, there were terms for the style, terms for the type of sand, terms for the properties of the sand, terms for the quality of the sand, and even terms for the failures of the sand.
You may be thinking that computer science has terms. What about linked lists? hash tables? queues? Ok, what kind of linked list are you thinking of? Singularly linked? Doubly linked? Circular? Do those hash tables allow duplicates? Does that container have value semantics or reference semantics? Is that queue FIFO or LIFO?
When it comes to defects, we're even worse off. Most programmers are still refering to defects as bugs, a term which was created when an actual insect crawled into the Mark II Relay Calculator and caused it to fail. The operators were quite proud to find the problem, and taped the moth to their computer log with the notation: "First actual case of bug found."
Today we still chase bugs, but their problems of our own making. Most the time we're chasing our tail, or scratching our head reading problem reports from users, which contain helpful information like: "it died", "it crashed", "it stopped working" or "my computer froze". I don't blame the user for not wanting to give me a 500 word essay on where they were and what they were doing right before the problem appeared, but my only hope is to try and reproduce the problem myself or fire back an equally helpful response, "unable to reproduce, need more data."
Another area software engineering could learn from metalcasting, is in the area of specialization. There are a lot of different types of casting, and while someone serious in the field probably specializes in one or two, they probably have at least an introductory knowledge about most types. In software, we still haven't acknowledged that embedded programming is a different speciality from enterprise infrastructure, or natural language processing. After finishing a desktop application, the software engineer is just as happy to start working on a printer driver, as he is to start writing java beans; with very little thought to the change in landscape.
I think a proper education or training should include various types of programming tasks, with different constraints (limited memory & CPU, reliability issues, speed of development/rapid prototyping, interpreted vs compiled language development, design with evolving and changing specifications), and some discussions on the differences in working in each enviornment. Heck, why not have them even do some assembly programming and learn about a few basic rules of hardware, like the rude things the real world does.
The difference between theory and reality can be rather large when it comes to signals from the real world, even with something as simple as a switch. To a human, when you switch on a switch it goes on, but electronics are a lot quicker than we are, and they notice things that we don't. Like the bounce a switch makes when it first switches. Turns out it doesn't go on immediately, but rather bounces around a little before settling down. If you want proper results you have to somehow dampen the signal electrically, or de-bounce the input in software with a routine something like this:
Not doing this can cause much frustration and problem. I'm reminded of a particularly cranky piece of hardware that just about ended up being thrown off a six story building, which would have been bad.PROCEDURE check_input(new_val) static last_reported, last_seen, seen_count ; IF (new_val == last_reported) THEN return ; IF (new_val <> last_seen) THEN last_seen:= new_val, seen_count:= 1; ELSE seen_count ++ ; IF (seen_count > kDebounceCount) THEN BEGIN last_reported := new_val ; report(new_val) ; END ;
It was 1999, and I was flying around the world doing Y2K upgrades on machines so that they could continue to track imaging satellites when the year rolled around. This particular stop was at Crisp in Singapore, and they were also switching their recording gear from D1 tape to a disk array. To facilitate the switchover, they needed a time-source with both NTP ethernet support & analog IRIG-B outputs. Someone had found a box with both connectors and so it was on my list to install.
This was one of those boxes that originally did not have any "user settings", so the addition of things like a network port which needed an IP address were sort of shoe-horned into the limited interface already present. With a one line LCD display and four buttons, I was supposed to setup several features, including its target address of 192.168.2.117. After wandering around in a multi-level menu, I got to the proper screen and started the boring task of entering in the address one blip at a time (kind of like drawing a picture with morse code).
0, 1, 3, 4, 5, 8, 9, 10 ... 190, 191, 193 arg 194 195 197 ... 0, 1, 2, 3, 6, 7, 8 ... 190 careful tap 191 careful tap 193 grrrr"Where's the hammer?"
"No, you cannot use a hammer."
"Just one tap, just to remind it what the possible future holds."
"No, we can't break it. We are half way around the world from a spare to replace it."
"We don't even need it. We can just use NTP on the SGI for the time recording on the satelite tapes until the replacement gets here."
"We don't need it technically, but the contract says NUS gets one, so the upgrade won't be complete unless they have one, which means they won't sign-off, and we don't get to leave until they sign-off."dang it 195, 196, 197, 199 ...
