Regulating Alchemy

Some call software development a science, an engineering discipline, or a profession. But in fact, the current state of the field more closely resembles alchemy.

Image credit: qimono (Pixabay)

Let’s not dig too deep into the metaphor–just let alchemy stand for this combination of things: dangerous processes that poisoned people and blew stuff up, fantastical goals to turn things like lead into gold or to discover some sort of cure-all elixir, and a bunch of coincidentally useful processes and outcomes that eventually became stabilized and understood through modern scientific methods.

There are some who look at the software industry and see the various dangers and flaws and risks in the way we do things, and they want to fix that. They also see how we fall short of our fantastical goals, and recognize the need to improve on that as well.

Our modern day software alchemists aim to solve these problems primarily through Divine Processes, Tools, and Methodologies–including but not limited to things like Test-driven development, Pair programming, Scrum, Object-orientation, Functional Programming, Vim, and other things I could put on this list just to rile up people who are attached to such things. (cough-Escape key-cough)

In the right setting, each of these Mystical Artifacts actually do produce useful results; sometimes they’re even repeatable if you can constrain the problem space well enough. However, to acknowledge that point does not diminish the larger point: we still have none of the prerequisites in place to turn software development as a whole into a true profession. And when I say none, I mean none.

Now I know this is where I’m supposed to list out what those prerequisites are, to lay out some sort of path (even a vague one), from software alchemy to software chemistry. I’m sorry to say, I don’t have that yet. But simply asking the question will drive me (and hopefully you) to start searching for the answers.