You know who this guy is? Probably not, he's Rube Goldberg.
I'm surprised by how few engineers know his work. Rube Goldberg was a cartoonist who lived from 1883-1970, he's famous for drawing cartoons of ridiculous and inconceivably complex machines. His work was important during a time in which the world was becoming increasingly mechanized and automated providing a sort of cultural "steam vent" - a way for people to poke fun at machines and industry. I'd embed his work here, but none of it is public domain, so see for yourself or search Google Images. (Be warned, you can spend hours looking at these cartoons.)
I learned about Rube Goldberg from an Engineering professor who, at the time, said, "Rube Goldberg is the most important thing you'll learn over the next four years". Back then, we all thought he was joking, but it turns out that he wasn't. In fact, I wish more people, especially "build engineers" had some exposure to these cartoons. If they had, they'd take a step back and realize that there has to be a better way.
The title of this section is the Webster's New Dictionary's definition of "Rube Goldberg". Does this describe your internal software distribution process? I fear it might. I've seen some builds and deployment procedures that convince me that people are actively trying to create new Rube Goldberg machines with SCM tools and build scripts. Almost every month I see some new variation of what I eventually characterize as a "Crazy Rube Goldberg" approach to releasing software. Systems that barely work, and that no one dares to change for fear of breaking some crazy contraption.
Goldberg's cartoons and the build's inspired by them share common characteristics. The complexity of his cartoons are almost always defined by the complex ways in which some object is transported from one "stage" of the cartoon to the next and the comic "indirection" involved in every process.
A cartoon example, a man slips and falls, stepping on a switch which then activates a mechanical hand that throws a bag of sand on to a scale which then triggers a mechanism to fire an arrow at a balloon. A build example, Jeff runs a build on his laptop because that's the only place release builds work properly, he then checks the WAR into Subversion and then sends a series of emails to several other people. A deployment engineer then takes the output of Jeff's build and runs it through a custom, somewhat confusing Perl script to customize a series of configuration variables.
The common characteristics between Rube Goldberg cartoons and Rube Goldberg builds are:
Unnecessary Indirection
Reliance on the Unlikely
Reliance on Animals (or Humans)
Comedy
If they work, they can be. It's quite common for the build/deploy lifecycle at a corporation to involve a series of steps that no one fully comprehends. Maybe there's a crazy 4000 line Ant script or maybe there's a multi-headed Hydra of bash magic that happens to produce a working system. In the last few months I've talked to people with build systems that work, but no one on staff understands how. When you ask about these release procedures people often chuckle a bit - "Oh, right, our release process.... well let's say it's a little confusing...".
"Why does the build do it like this?" is often met by, "I don't know, but I'm too scared to change this thing right now, the contractor left us with this and it works... for now." In other words, many of these builds involve a series of unknown pulleys and unexpected indirections that resemble a cartoon.
In the next part of this series, we're going to talk about how Nexus can be used to untangle a build into something more reasonable. Something that doesn't involve pulleys, magic, and a series of unlikely events.
Note: Rube Goldberg doesn't do it for you? Then just watch the OK Go video "This Too Shall Pass" to get a modern idea of what I'm talking about. If you haven't seen that, you should. In fact, if you haven't seen this video yet, stop reading our boring Nexus blog and take a break, it's worth it.