Aluminum Wiring in Your Software

A friend recently had to replace some electrical outlets in her house because they stopped functioning. There was so much corrosion built up between the aluminum wiring and the outlet contacts that the outlets quit working (which is much better than the alternative - catching on fire). aluminum wiring

Did you say aluminum wiring?

During the classic rock era of the 1960s and 70s, aluminum wiring became a popular replacement for copper wiring in the USA. Due to a copper shortage, aluminum was cheaper than copper and allowed electrical contractors to lower construction costs. I was quite shocked to hear about aluminum wiring in her home, I’ve only seen copper myself, but according to the CPSC there were ~2 million homes with aluminum wiring by 1974.

Over the years, a number of problems with aluminum began to surface. Aluminum wiring is more brittle than copper, and much more likely to oxidize, corrode, and overheat. Aluminum wiring just isn’t as safe as copper wiring* and is now banned in the electrical codes of many jurisdictions. Aluminum wiring lives on in many houses, however, because it’s expensive to swap out a piece of embedded infrastructure like wiring.

Hindsight is 20/20

Engineering is always about tradeoffs. But many times we start using a technology, tool, or methodology because it appears to save us time or money. It’s only later that we can see the problems clearly.

My question for you is:

What do you think is the “aluminum wiring” inside today’s software? What have we adopted recently that we’ll look back on in 3 years and say “ouch”.

Here are a few candidates to start the conversation (based on an informal poll of random developers I accosted):

  • Mock objects
  • Fluent APIs
  • Declarative programming
  • Anything that isn’t a UI but requires a visual designer to create or edit

 * If you are replacing outlets with aluminum wiring coming in, please, please, please be sure to use an outlet made for aluminum. They are more expensive, and the young clerk at the store will try to sell you an outlet for copper wire, which can be a fire hazard.

Print | posted @ Tuesday, March 17, 2009 2:38 AM

Comments on this entry:

Gravatar # re: Aluminum Wiring in Your Software
by ryan at 3/17/2009 3:17 AM

Nested functions in JavaScript like jQuery. It's impossible to debug.
  
Gravatar # re: Aluminum Wiring in Your Software
by Mike at 3/17/2009 3:52 AM

Not a UI but requires visual designer... Workflow! I'd say SharePoint, but you really don't need SPDesigner.
  
Gravatar # re: Aluminum Wiring in Your Software
by Simon Segal at 3/17/2009 6:07 AM

Why stop at nested functions in Javascript? ;). On a more serious note: over burdensome configuration - as per the WCF model, which runs counter to the suggestion that fluent API's should be in the list. I would prefer a fluent API that can be plugged in.
  
Gravatar # re: Aluminum Wiring in Your Software
by Samuel Jack at 3/17/2009 9:28 AM

It seems like we are just reaching the conclusion that all-pervasive XML was the Aluminium Wiring of yesterdays software.
  
Gravatar # re: Aluminum Wiring in Your Software
by scott at 3/17/2009 1:25 PM

@Samuel: Here is the link you wanted, not sure why it changed it on you:
codebetter.com/...
  
Gravatar # re: Aluminum Wiring in Your Software
by Shane Courtrille at 3/17/2009 9:19 PM

In terms of Mock objects the only way I see that happening is if someone finds a better way to do indirect output testing and I just don't expect that to happen in a way that is any help for the old code bases.

BUT Mock objects have actually already had an aluminum wiring moment, which was the usage of Strict Mocks. It seems like a lot of people (myself included) got started with Strict Mocks and the one lesson that came of that is that while they have a usage; it's a very limited usage. Using them everywhere leads to brittle tests everywhere. There are quite a few projects out there with strict mocks running throughout their tests. Sitting there quietly waiting for the day someone changes a single line of code and they can blow up.
  
Gravatar # re: Aluminum Wiring in Your Software
by Jeremy D. Miller at 3/18/2009 12:16 AM

Ditto to most of the list, but I think we just don't completely understand the best ways to build and consume FI's yet (you should really say Internal DSL's). I wouldn't throw out FI's just yet. Do look at nested closures and object scoping to make FI construction and consumption easier, and lay off of runaway method chaining and nested functions that make FI's harder to use and read.

Coding in Xaml, strict mocks, and WF can be happily tossed onto the trash heap as far as I'm concerned.
  
Gravatar # re: Aluminum Wiring in Your Software
by Milan Negovan at 3/18/2009 2:04 PM

I says, pour some Coke on the oxidation. I used to clean my car battery terminals like this. :)
  
Gravatar # re: Aluminum Wiring in Your Software
by XML Heretic at 3/25/2009 10:12 AM

XML Everywhere

It's just plain wrong. I've been in computing for years and spent a fair deal of my time getting systems to communicate together, and never needed to have human readable messages. It's a computer, let it talk in binary. Duh.

By all means define the conversation schema in some format that can be understood by humans and machines, but don't bother sending this more than once, and don't bother polluting the data with it. Once a communication link has been setup between machine A and machine B, there's absolutely no point in transferring anything other than raw binary data - it's smaller on the wire and hence quicker. As long as both ends understand the format then you're sorted.

One day someone will agree just how crass using XML is.
  

Your comment:

Title:
Name:
Email:
Website:
 
Italic Underline Blockquote Hyperlink
 
 
Please add 5 and 3 and type the answer here: