Software Development: Applied Metaphysics?
I’ve been playing around with a thought. What if the metaphor of software development as engineering isn’t wrong insofar as software development could never be made as rigorous as engineering, but rather, perhaps its wrong because of the assumptions loaded with engineering? After all, when we say engineering, we generally are talking about applied science and technology of physics.
Perhaps its the case that software developers are engineers, but of a different sort. Perhaps they are practitioners of applied science and technology of metaphysics? This definition itself is a little hairy, since one could argue that the sheer concepts of science and technology are metaphysical ones. Perhaps it would be better said if we simply said software developers were applied meta-physicists?
After all, the debates over immutability of data versus mutation harken all the way back to to the presocratics and the famous quotation attributed to Heraclitus that one never steps into the same river twice. Arguments over substance sound eerily familiar to that over object oriented programming. Finally, the introduction of process philosophy by Whitehead can be tied very easily with the ideas embodied by event driven programming.
The tie of software design to metaphysics seems obvious upon reflection. It is our job to listen to loose descriptions of our clients worlds and try and encode them into a rigorous system of objects, relationships, processes and data – so rigorous, in fact, a computer can follow through with them. One of the hardest problems in computer science, it is said, is naming things, which is very much a hard problem in philosophy. The corollary to metaphysics also explains one reason why software design is so amorphous and hard to nail down, while software itself is ironically very rigorous once written. Meta-physicists do not yet have the tools of science, mathematics or empiricism. It is in fact the very same philosophers who invent those tools. Much like C style object orientation, they have to use tools that their language doesn’t necessarily give them, thus rely on convention over configuration, to a degree.
Software engineering as a psychological pursuit surely will come under the knife of science in time – we can measure whether or not teams that pair program, test-drive design and object orientate their work are more or less productive than others. But the source of those ideas and processes itself will always, it seems, live in the realm of metaphysics which can only loosely be attacked through rational debate (notwithstanding the assumptions one must make to even get to the point where you’re allowed rationality).
No comments yet.