This past weekend I replaced the brake pads and rotors on my car. It took a couple hours, cost about $90 in parts, and left me not just with a sense of achievement and personal satisfaction, but a with lots of thoughts about how mechanical systems work, how standardization should function, and how these things translate into the world of software design and development.
The aftermarket auto parts industry is huge. In my area, there are at least 3 national brand auto parts retailers. They stock thousands of parts for hundreds of makes, models, and versions of automobiles. They can do this because of standards. A brake pad for my vehicle can be made by aftermarket manufacturers because they can develop against a standard, ensuring the part will fit and perform as expected in my car. Most of these aftermarket brands boast how they “meet or exceed the original equipment manufacturers standards…”
As an end user of my vehicle, if I am so inclined, I can perform the task of replacing worn out parts with new parts. I can do this in many cases without any particular training or expertise, or the need for specialized tools. I simply dismantle and remove the old part, and install the new part. And most of the time, it just works.
But when was the last time an end user could replace a broken block of code with a different block from another manufacturer?
Never? Rarely? Oh, silly man, that’s not how software works!
I concede, a hunk of metal is a lot different than code that can contain logical or programmatic errors. If the metal wears out or doesn’t perform, we just cast another one and put it in its place.
There are a few key points that emerge in this discussion.
- Ownership versus Licensing
- Open versus Closed Source
- Software aging and reuse
Ownership vs. Licensing
When I purchase an automobile, I (or the bank) own it outright. There may be a manufacturer’s warranty in force, but the manufacturer has no claim to the tangible asset. It becomes my property, and I am largely free to do with it what I want.
Software is a different animal because it is a licensed product. In the majority of cases, what I buy when I purchase a piece of software is permission to use the product, not the product itself. For example, here is the first clause from the OS X Mountain Lion license agreement (emphasis mine):
1. General.
A. The Apple software (including Boot ROM code), any third party software, documentation,
interfaces, content, fonts and any data accompanying this License whether preinstalled on
Apple-branded hardware, on disk, in read only memory, on any other media or in any other form (collectively the “Apple Software”) are licensed, not sold, to you by Apple Inc. (“Apple”) for use only under the terms of this License. Apple and/or Apple’s licensors retain ownership of the Apple Software itself and reserve all rights not expressly granted to you.
Thus, by agreeing to the license, I have no right or authority to modify, enhance, customize or otherwise repair the code. I must take it as is, trusting that it will work as expected. If it doesn’t, I am at the mercy of the producer to deliver a patch. Otherwise, I’m stuck.
(Note: for a far more educated perspective on this topic, I recommend the Freedom to Tinker blog by Princeton University professor Ed Felton.)
Open Source vs. Closed Source
The advent of Open Source software in the late 1990s challenged this traditional form of licensing by opening up the ability to view, change and customize the code covered by the license. Still, most commercial software is closed source and tightly guarded by its licensing terms. My ability to modify the functionality of the product is limited to the configuration settings or integration points exposed by the creator.
Software Aging and Reuse
Generally speaking, software doesn’t wear out. The code written 10 years ago, given a suitable runtime environment, should still work. A one is still a one, and a zero is still a zero. Unlike my brake pads, which degrade every time they are used (albeit ever so slightly), software code does not break down with each subsequent execution (unless of course it was designed to do so.)
Most software improvements and future versions are created to add features and repair bugs. In some cases, producers may rewrite products from the ground up in order to take advantage of the available tools, hardware specs, and methodologies that are in play at the time. But the old code, left as is, doesn’t stop working just because it is old and has been used repeatedly.
So if software doesn’t wear out and is not mine to modify, is there a comparison to the replaceable parts of my car? I still think so.
Designing for change
Software in its own way is purposefully rigid. You want it to do one thing well. Until you don’t. At that point you want the flexibility to make it behave differently. And if you are so inclined, you’d love to do it yourself.
Not all products do this because designing in that kind of flexibility takes more time, costs more money, and requires more effort.
The best example I know of such a product is the very tool I am using to share these thoughts. WordPress has a pretty amazing capacity to accept add-ons from 3rd party developers. As an end user, if I want my blog to have advertising, or my Twitter feed, or be an ecommerce site, I don’t have to wait until the WordPress creators add these features as officially sanctioned behaviors. I simply add a plug in. If the first one (or ten) I check out don’t do it the way I want, I have more to select from. If all else fails, I can write my own.
The internet browser is another class of software that is becoming more modular. Whether they are called ‘add-ons‘ or ‘extensions‘ or ‘accelerators‘, they all serve to let me as the end user tweak and adjust how the product works.
Perhaps these plug-ins are more akin to putting a new stereo in my dashboard to replace the factory installed unit than they are to replacing a worn component.
Designing modular, extensible software can be a challenge. I believe though that there are certain advantages to do so, particularly for consumer products. Now it’s time to press software creators for more of that freedom.
