There has been a recent spike (well relatively ancient in software terms...) in the term Software Craftsmanship. This is the notion that developing software bears more resemblance to a craft or art than to a scientific pursuit. This is a very accurate and a good explanation for why guilds and other artisanal concepts creep into software development circles.

I've noticed interesting contrasting correlations in folks who "grew up" developing software to solve problems versus people who learned computer science or computer engineering at a university. While the latter generally have a more sound grounding in the theoretical underpinning of "how computers work", the former have a better grasp at "how software delivers value". Put another way, computer scientists and computer engineers seem to have a focus on the nuts and bolts of how computers work instead of how to get them to do new and valuable things.

This is not a BAD thing, but losing sight (or not focusing on) "how what I'm building adds value" and instead focusing on "how the computer does stuff" tends to lead to what I'll term "science experiments". Using a different metaphor, a craftsman finds tools that are "good enough" for the job and spends a little effort of time to constantly refines them whereas a scientist will spends a LOT of effort over time finding or building the "perfect tool" for the job and little effort to actually do "the job".

Put another way, if I want to build something out of wood, I could spend days/weeks/months studying the various characteristics if different kinds of wood, or I could build a cabinet out of whatever lumber I can get my hands on and refine my techniques as I progress through more projects with different kinds of wood. I find the latter to be a more useful approach, unless my value proposition is that I want to be the foremost expert on "all things wooden". To illustrate the difference I ask the question: "Do you want your cabinets built by someone who has built many progressively better cabinets with a variety of materials, or by someone who has never actually built anything, but can explain the shear strength of cedar versus maple?".

While I realize this is an oversimplification (well maybe not as much as we'd like to admit), where I find a particular weakness in the industry right now is in developing the "craft". Too often, industrialized software development ignores a particular aspect of craft, that is, the continuous improvement of your tools and process and instead focuses on a particular "perfect technology" without refining the art. I've seen too many developers focus on finding the "perfect tool" instead of learning how to work with the ones they already have... the process of learning new tools and techniques better serves "building useful things" when it is constant and evolutionary instead of intermittent and revolutionary.