Orange County Choppers

Last night I was watching an episode of "Orange County Choppers" (http://www.orangecountychoppers.com) - I don't know if you've heard of this show or seen it but it's the reality show on the Discovery channel where the daily on-goings of the OCC Custom Motorcycle shop is followed. The owner, Paul Sr., has a short fuse and his sons Paul Jr. and Michael ("Mikey") work at the shop under him. A lot of tension exists between the guys during approaching deadlines and it's great entertainment. Being that I live less than an hour from the shop, I try to watch it regularly.

Anyway, last night, they were starting to build the "I,Robot" promotional bike and Paul Jr.'s job was to fabricate and install the exhaust pipes in an artistic and yet functional way - as is the case with every custom bike they build - especially for high-profile events like movie releases. During this episode, a day and a half of real time went by and Paul Jr. had an initial idea and design for the exhaust and he had it put on and shaped, and the pipes bent and welded all to come to the final conclusion - after a day and a half - that what he saw he didn't like. Paul Sr - the owner - was pissed at Paul Jr. and began screaming 'just get it done' with the deadline for completion of the bike looming only a few days away. Bantering went back and forth for a while and it was fun to watch the arguing from the safe distance of my living room.

At that point, I couldn't help but realize that there was strikingly similar correlations between what happened in the past day and a half at OC choppers, and parts of my personal 10 year career in the software industry. The reason that I say this is because software, at least in my personal experiences, is a mix of artistic taste and preference, technical mandates (both from customer requirements, and the enforcements placed upon it from the previous artistic decisions and other technical decisions), and time/budget constraints (the 'get-it-done' mandate). This struck something in me that lead me to believe that in this sense, building software - at a high level - is very much like building a customized "I,Robot" bike. Extending this idea, I am now thinking that the analogy between software and some tangible product is more like that of a vehicle - a car or a motorcycle - than a house or building.

One of the reasons that I think this is so is that the construction industry primarily deals with non-moving, static, and pre-measured components that do not vary by much between vendors. A 2x4 is a 2x4 is a 2x4. Some are pressure treated, others made from different varieties of wood, but by and by, a 2x4 is substitutable for any other 2x4. Likewise, doors, faucet fixtures, light fixtures, etc are interchangeable between one another because there are really only one or two real functional specifications that need to be matched - i.e. 5/8 inch diameter, or 120Volts AC. The artistic dimension is left up to the home owner to choose from - this is where commoditization comes from.

A car's alternator however, is not interchangeable - even if the specifications are the same - i.e. convert AC power from the engine to DC power to recharge the battery - at 14.9 Volts DC. I can not take my 1998 Honda Accord's alternator and put it into my brother's 2001 Chevy Impala. They both do EXACTLY the same thing - and probably have the same if not very similar specifications, but their shape, and their position in the engine cavity, and the size of the belt, etc. are different enough to require customization. Likewise, in a house, nails are interchangeable - for the most part - however, in cars, the bolts that hold the parts together are extremely variable in size and thread from model to model.

There are countless other correlations, but the point I want to make is that the difference between how houses are built and how cars are built is really staggering. Houses are very much custom jobs all made possible because of the minimal requirements and enforcements in 2 of the 3 variables of software design influences I mentioned earlier - artistic tastes, and time constraints. The final influence, functionality, really doesn't exist either but it does exist for houses. Of course, houses need to function as living quarters, but those requirements are standard and don't really vary.

In vehicles however, all 3 variables are extremely important - especially given the nature of the reduced spacial real estate that a car occupies versus that of a house or building. The functional requirements take a much greater role in the creation of a vehicle more than any of the other 2 variables I mentioned. Therein lies the big insight that I believe is key to correlating the auto industry to software - the force of constraints. I would argue that if a server existed that had infinite CPU and storage resources, then the software industry would immediately have no choice but to commoditize itself - and then become more like the construction industry. What could software vendors differentiate themselves on? Speed? Efficiency? Feature set? Well, with hypothetical hardware of infinite resources, speed and efficiency don't matter - all software runs at the same speed and efficiency. Features can be competed on, but over time, all features would be implemented very very quickly because who cares how sloppy the code is - as long as it works - every feature will eventually get implemented. In such a model, the software industry would resemble the construction industry because in construction, the time constraints are usually not enforced as much - especially for a DIY home owner. Also, the physically vast spacial dimension of houses reduces the functional requirements of components to one or two basic requirements. This leaves the artistic dimension to be used freely with very little limits - which is why no 2 houses are really alike (except in pre-fab).

This is kind of like how open source works right now because the constraint of time is effectively removed and the constraint of functionality is lessened because of the massive number of hands-on writing of code - someone will make an OSS project functional, and there are thousands of others to help. OSS is extremely functional as well as very artistic (not necessarily in a GUI sense), because of the reduction of these constraints which makes OSS kinda like building a house, but software in general is like building a car because of the introduction of more and more constraints.

Therefore, I tend to agree with your conclusion that OSS can be equated to construction, but I would argue that until we get to the point where we can reduce or eliminate some of the constraints, software integration, customzation, and services at the high levels where you can 'make money' will always be like building cars.

To bring this story home, just like in the OCC Choppers episode, there comes a time when one of the constraints will start to outweigh the others - in this case, time was running out - therefore artistic design and functionality start to take a back seat. Functionality is of course important, but as long as the minimal is met - i.e. get the fumes out of the engine - the sooner a job can get done, the better. This is what causes software to be of lesser quality and have less artistic influence as that compared to OSS software.

At least that's what I think.