My primary hobby in my off-time is blacksmithing. Blacksmithing as a profession effectively died out in North America in the 1950s/1960s, but was reinvented as an art during the 1970s. There are still incredibly few blacksmiths still around, but it is an extremely rewarding hobby. This series will examine how blacksmithing and mobile software development, two seemingly disparate pursuits, share a lot more in common than you might suspect.
In Episode 2, I will discuss how both professions, blacksmithing and software development, have changed when it comes to passing down knowledge from one professional to another.
Historically, blacksmiths only passed down knowledge from master to apprentice. If you knew something that a fellow blacksmith didn't, you had a competitive advantage over him, telling him about it would have erased that competitive disadvantage. You would not have known any other blacksmiths that you were not in direct competition with, given the difficulty travel imposed on us before the advent of motorized transport (particularly when trying to transport things like anvils, which commonly weigh at least 150-200 pounds). Indeed, a master typically only taught his apprentice a subset of what he knew, in case the apprentice setup shop in the same community. Only in the scenario where the apprentice was related to the master would his full set of knowledge be passed down.
As a result, the progress in the overall increase in the amount of knowledge that blacksmiths had was extremely slow. Many blacksmiths were forced to reinvent or reengineer the same techniques that had already been discovered hundreds of times over somewhere else.
When blacksmithing reached near-extinction, there was a sudden frenzy of activity to publish known techniques before they were lost forever. When the craft was revived, that knowledge was passed around, shared, and added to. With the advent of the internet, and sites like YouTube, this information has exploded exponentially. Techniques that blacksmiths spent years rediscovering can be learned in a matter of hours.
Software development went through a similar process, although obviously in a dramatically shorter time period. When software was first being produced, there was only extremely limited information sharing, basic programming techniques, anything a company produced that gave it a competitive advantage was kept proprietary. If you used code from another company, it was supplied to you as a library whose code was inaccessible to you, you were given only the interface. You could always reverse engineer how it was done, but this was a slow, tedious, and error-prone process at best.
Over time, however, the open source movement took hold, and companies began to understand the benefit of sharing code so that everyone could work as a community to product a better result, faster, than individual companies could do by themselves. If you wanted a language parser two decades ago, you had to write it from scratch. Today, you can find multiple versions you can use for free. Similarly, if you ran into an obscure (or not so obscure) error you couldn't solve yourself, you used to have no alternative but to ask around your local colleagues and, failing that, continue bashing your head against the wall until you figured it out. Today, you can simply type it into Google and have a remarkably good chance of finding out the solution.
The analogies aren't perfect, however. The incredibly few full-time, professional blacksmiths who are still in business are typically separated enough by geography and area of specialization as to not be in true competition which each other, and thus suffer no significant hindrance by cooperating. There are obviously a huge number of software development companies that are in competition which each other, geography being almost entirely irrelevant in the modern economy for a fundamentally virtual product, and no company can carve out a niche it occupies by itself for very long. This reflects in the type of information shared via open source, it is virtually always generic, niche-specific functionality is kept proprietary.
Moreover, the sharing of information is not entirely beneficial. The blacksmith forced to rediscover a technique may actually discover a better one. If all he does now is read a book or website or watch a video, all he learns is what is already known. Moreover, what that book or website or video says may be wrong, or at least inefficient. Similarly, we, as software developers, must not fall into the trap of taking what Google tells us as scripture. The answer that someone else found, or claimed to find, might be not be right, or it might be right but suboptimal, and it might even be dangerous. Having that information available to us is a tool (sense a theme?) we can use in pursuing the end result, we must not treat it as the end result itself.
In the product I work on, my team has gone out of its way to publish numerous (20+) samples, not to mention helping to answer hundreds of questions on a variety of newsgroups. We must continue be careful, however, that the consumers of this information use this information as aids, not as crutches.
