Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Orthodoxy vs. Pragmatism, or How I Became a Better Developer

It is a distressing thing to see how much of programming today is still discussed in terms of all-or-nothing propositions. Whether it's the insistence that one language, or type system, or model of development is inherently and universally superior, I find the lack of nuance troubling. Life has taught me well that most of the benefit of techniques and technologies lies not in their absolute or universal application, but rather in using them with discrimination.

More Insights

White Papers

More >>


More >>


More >>

The dogmatic insistence on using one exclusive approach rings of inexperience or, if proclaimed by an experienced hand, a lack of thoughtful consideration. When young I was and green, I had all kinds of ideas on how code should be written. Since I was inexperienced — and didn't appreciate how inexperienced — I would passionately argue for techniques and tools that, in retrospect, I only partially understood. Mostly, they appealed to me for some aspect whose limitations were a sealed book, but whose benefits were completely obvious — if only I could get others to recognize them, too. I was full of wonderful ideas and remedies. I was living the life of an insufferable fellow, but enjoying it because, dang!, I just knew so much. And where I lacked specific knowledge, I relied on people I admired, who used this or that tool or some special technique. If it was good enough for them, well, it was good enough for me, let me tell you. (Today's more common equivalent is, "My professor says that…")

Maturity brought wisdom and I began to realize that few indeed were the tools and practices that could be recommended universally. I also started to see that even for proponents of various techniques, there was always wiggle room. Exceptions to blanket rules were not to them evidence of imperfection in their beliefs, but validation that the real world could not be entirely reified to comply with a single edict.

For example, let's take a practice that seems to elicit more religion than many others: test-driven development (TDD). The steps in TDD are all well-known, formulaic, and perfectly set up for doing all things exactly one way. A key principle of TDD is that you write no code without first writing a failing unit test. But in fact, if you talk to the principal advocates of TDD (such as Kent Beck, who popularized the technique, and Bob Martin, who has taught it to thousands of developers), you find that both of them write some code without writing tests first. They do not — I should emphasize this — view these moments as lapses of faith, but rather as the necessary pragmatism of the intelligent developer.

It is tempting to view programming in moral terms because we so often refer to code as good or bad, but programming lacks the defining overarching moral imperative towards which good things tend. To wit, the frequent example of the three divergent poles in programming: good, fast, and cheap. Different projects work within the constraints imposed by individual blends of these properties, which is why a CRUD app has more tolerance for errors than a pacemaker — and why holding that some practice is the right way in all circumstances is bound to be wrong. Such a view, in my opinion, is a meta-level code smell.

Even if we limit ourselves to a smaller segment of software — for example, pacemakers — the way forward is certainly one of discipline and rigor (within the constraints of quality-performance-cost), but not orthodoxy. Where exactly is the line drawn? It is, in my opinion, wherever activity that is valid in one area is extended beyond the area of its benefit. Let's choose a simple example: commenting. If the rule is to comment all code, then orthodoxy has prevailed over pragmatism. Such excessive commenting is likely to be costly, slow, and bug-ridden. That is, all three vectors point the wrong way. 100% test coverage of is a more subtle example. It's the extension of a good idea to every aspect of an activity — almost always a sign of orthodoxy. I could go on with other instances, such as language selection, agile and DevOps practices, testing, and nearly every other aspect of development.

The best programmers I've met are not only intensely pragmatic, they actively pursue pragmatism. They look at new technologies, so as to avoid choices made inadvertently orthodox by ignorance of alternatives. They use tools in a balanced way that ruthlessly seeks delivery of intended results within the established project constraints. The more I work like them, the better programmer I am.

— Andrew Binstock
Editor in Chief
[email protected]
Twitter: platypusguy

Related Reading

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.