Aluminum Wiring in Your Software

Tuesday, March 17, 2009

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.


Comments
ryan Tuesday, March 17, 2009
Nested functions in JavaScript like jQuery. It's impossible to debug.
Mike Tuesday, March 17, 2009
Not a UI but requires visual designer... Workflow! I'd say SharePoint, but you really don't need SPDesigner.
Simon Segal Tuesday, March 17, 2009
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.
Samuel Jack Tuesday, March 17, 2009
It seems like we are just reaching the conclusion that all-pervasive XML was the Aluminium Wiring of yesterdays software.
scott Tuesday, March 17, 2009
@Samuel: Here is the link you wanted, not sure why it changed it on you:
codebetter.com/...
Shane Courtrille Tuesday, March 17, 2009
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.
Jeremy D. Miller Wednesday, March 18, 2009
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.
Milan Negovan Wednesday, March 18, 2009
I says, pour some Coke on the oxidation. I used to clean my car battery terminals like this. :)
XML Heretic Wednesday, March 25, 2009
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.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!