Software development decisions are often not scientific. We make technical decisions, and we often mistake the technical for the scientific, but our decision-making process is usually one that often reflects ideological machinations and adherences rather than the objective assessment that requires us to question the things we’ve chosen to cling to.

Without an objective standard to determine whether our software decisions are either helpful or harmful, we’re left with the worst possible means of arriving at conclusions: We do what others are doing. And this is the principal means of decision making in most of software development.

We reduce to a mere popularity contest something that is already able to be distilled to objective measures. And because we’re relying on something as flimsy and subjective as a popularity contest, we volunteer ourselves to the unscrupulous manipulations that win popularity contests. In the process, we remove ourselves from the sphere of influence of the very knowledge and learning made available to software developers for assessing the soundness of our decisions and the software that results from them. And in the most heartbreaking of cases, we allow bullying and social shaming to have the last word on matters that are readily-decided by plain old structural dynamics and structural physics.

This isn’t something that’s unique to software development. It’s common to every emerging technical field, and software development’s scant 3 score years puts it squarely in the “emerging” category.

In their lifetimes, both Louis Pasteur (1822 - 1895) and Ignaz Semmelweis (1818 - 1865) pleaded with the overwhelming majority in the medical community to sanitize their hands and instruments or else risk contaminating and killing their patients. The germ theory of disease was largely unwelcomed by physicians of the age, despite having been proven by Agostino Bassi in experiments decades earlier.

Physicians could not detect the subtle factors causing sickness. Worse yet, physicians rejected the very possibility that they could be the very cause of sickness. They were, after all, the epitome of the scientific hero image of their time. How could such grand and anointed magicians possibly be wrong?

How could something that causes such a flagrant and obvious effect as the death of a physician’s patient be beyond the ability for such grand figures to detect?

And of course the answer is trivially-obvious: The causes of disease were beyond the unaided perceptions of any human being who has ever lived and who will ever live. But the physicians took the possibility of not being supermen personally. And they not only rejected the science outright, they attacked it with great vigor and violence, seeking to discredit it and destroy the reputations of its purveyors.

Software development is largely at the same point of evolution in its time as medicine was in its time in the 1800s. And like all contemporaneous adherences, we cannot accept that we the grand and glorious magicians of code might possibly be wrong - really, really wrong. After all, we represent the ultimate evolution of software development thinking - even though software, no matter how high tech, remains largely a human field that has not outgrown its adherence to superstition and idolatry.

And like those physicians of the 1800s, when we 21st-century software developers put our hands on our patients, their viability tends to get worse over time rather than better.

In 2006, a now-infamous idea was introduced to the world of ORM+MVC web development: Fat Model, Skinny Controller. Whatever the original intent or value of the advice, it became deeply entrenched and utterly pervasive throughout the culture. Especially in the Ruby on Rails world where it originated during Rails’ infancy.

The problem: It was objectively wrong. It was always wrong. It was knowably wrong from the very instant it was conceived, and remains wrong to this day. It’s wrong because it neglects and contradicts the very science that predicts whether adherence to this heuristic will cause all subsequent work to become far more complicated, far more error-prone, and far more time-consuming. It will always be wrong.

It neglects the effects of afferent coupling on general-purpose modules. By doing so, it invites low cohesion which in turn acts as a feedback loop amplifying the vicious cycle of high afference on high generality. And even as I say this, I can hear countless voices saying to themselves, “This is just academic navel-gazing and bike-shedding that won’t ever be as practical as the things I need to get done in my job today.” And yet most of the setbacks, strife, and lost productivity in the day-to-day work of contemporary ORM+MVC styled application development can be explained (and predicted) by these principles.

And yet, the Rails community accepted this bit of pseudo-science as unquestionable edict. And that’s all it was: edict. Dictated, but never substantiated against objective measures.

Had it been examined through the lens of software design principles, it would have been rejected on the spot. It would not have taken a decade of progress away from those who would cling to the dictate without question. For it was handed down to the mere plebeian caste by the keepers of the great and unfathomable knowledge that shall not be questioned lest we risk reprisals from community gatekeepers. And who are common developers to question the sonorous and mellifluous voices of the great code magicians of our time? For they are pleasant to listen to, and how could anything with the appearance of pleasantry possibly be mistaken?

Meanwhile, Louis Pasteur’s voice echoes hollow in the fading distance: “Wash your hands! Wash your hands!”

“Navel-gazing” and “bike-shedding”. These are the word-weapons of the anti-science advocate. They seek to silence inquiry and dialog. They insinuate harm to reputation and thus livelihood. They’re the audible calling card of the tyrant hell-bent on not being unmasked as an impostor, not just one with impostor syndrome.

These words have no place in software development. That is, at least not a software development this is rooted in science rather than cult fundamentalism. They have no place in an organization holding the forces of entropy at bay long enough to allow the roots of a learning culture to become viable and self-sufficient.

The software design body of knowledge - the design qualities, the design principles, the patterns that derive from them, and the processes that guide us through the dark - is the science of programming. It’s the objective arbiter of software development decisions. It loosens the grip of subjectivity on software development decisions and externalizes them so that they’re not based exclusively on the fog of emotional responses. It denies an opportunity for bullying and shaming to extort outcomes that benefit the ease and luxury of some colleagues at the cost of the continued strife of others.

The application of software design science still leaves room for interpretation and disagreements about interpretations, good faith negotiation of meaning amongst colleagues, and an ultimate decision maker who has both the authority to break a stalemate and the integrity to make the decision for the good of keeping subsequent work free from the complications and setbacks of short-term decision-making and local optima effects.

It’s critical for countless reasons for developers to start applying software development science to software development science work in every moment, in every act, in every conversation, and every line of code. When we do this, we begin the journey of elevating software development from the depths artisanal arts and crafts subject to the whims of personal preference and personality cult to an honored place in the pantheon of production and product development industry.