Technical Difficulties from on Top of the Mountain
2005-03-15
  The art of the craft
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.

bronze dolphin

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.

open book

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:

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 ;
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.

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 ... 
 
Comments: Post a Comment

<< Home
Life in the middle of nowhere, remote programming to try and support it, startups, children, and some tinkering when I get a chance.

ARCHIVES
January 2004 / February 2004 / March 2004 / April 2004 / May 2004 / June 2004 / July 2004 / August 2004 / September 2004 / October 2004 / November 2004 / December 2004 / January 2005 / February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / May 2008 / June 2008 / August 2008 / February 2009 / August 2009 / February 2010 / February 2011 / March 2011 / October 2011 / March 2012 / July 2013 / August 2013 / September 2013 / October 2013 / November 2013 / December 2013 / December 2014 / February 2015 / March 2015 / July 2016 / September 2016 / December 2016 / April 2017 /


Blogroll
Paul Graham's Essays
You may not want to write in Lisp, but his advise on software, life and business is always worth listening to.
How to save the world
Dave Pollard working on changing the world .. one partially baked idea at a time.
SnowDeal
Eric Snowdeal IV - born 15 weeks too soon, now living a normal baby life.
Land and Hold Short
The life of a pilot.

The best of?
Jan '04
The second best villain of all times.

Feb '04
Oops I dropped by satellite.
New Jets create excitement in the air.
The audience is not listening.

Mar '04
Neat chemicals you don't want to mess with.
The Lack of Practise Effect

Apr '04
Scramjets take to the air
Doing dangerous things in the fire.
The Real Way to get a job

May '04
Checking out cool tools (with the kids)
A master geek (Ink Tank flashback)
How to play with your kids

Powered by Blogger