Earth to developers: Grow up!

If you're a developer reading this right now, chances are you're an idiot.

That is, chances are you code regularly in a language that should never even have been invented. Or maybe you use the wrong IDE or the wrong text editor or some version control system that can't possibly do the job. Maybe you're dedicated to a programming methodology that never works, or your release cycles are set up all wrong. You might debug your code the wrong way, or you have no idea which optimizations to switch on in your compilers. Whatever it is, all your projects are destined for failure.

[ Get software development news and insights from InfoWorld's Developer World newsletter. | And sharpen your Java skills with the JavaWorld Enterprise Java newsletter. ]

By the same token, chances are I'm an idiot, too.

Why are developers so quick to call each other idiots, anyway? Why are they so pigheaded in their beliefs, so quick to take sides and reduce everything to fallacious black-and-white arguments? Check out any developer forum or message board: It won't take long before you'll find some seemingly innocuous thread that has erupted into a full-blown flame war.

The list of hot-button topics is endless: Emacs versus VI. Java versus .Net. C++ versus Java. Eclipse versus NetBeans versus Visual Studio. Perl versus Python versus Ruby. Agile versus waterfall. Django versus Rails. Extreme programming versus Scrum. Git versus Subversion.

You'd be hard-pressed to find a more contentious group outside a "Star Trek" convention. Yet bickering about your favorite sci-fi shows is all in good fun. It's entertainment; it doesn't have any bearing on real life.

For many developers, on the other hand, programming is their livelihood. When decisions about tools and practices become polarized and zealotry takes the place of rational discussion, it not only wastes time, but lowers morale, causes communication breakdowns in other areas, and at its worst threatens the successful completion of critical objectives.

It's grown so bad in the app dev world that groups of developers have taken to issuing "manifestos," as if they were Central American revolutionaries. First there was the Agile Manifesto. Now others are trying to come up with the DevOps Manifesto (though the thought behind that particular revolution seems a little harder to articulate).

In that spirit, I'd like to propose a new manifesto for those developers who are tired of the partisan squabbling, flame wars, name-calling, and finger-pointing. For lack of a better name, I call it the Maturity Manifesto, and it's organized around a few guiding principles:

1. I will reject dogmatic thinking about tools, practices, and processes

If you find yourself returning to certain websites for talking points about why your favorite tool is better than all the others, there's a good chance you don't really understand your favorite tool well enough to argue as fervently as you do. Talking points are a great way to convince developers why they should try a new tool or become expert in one they already know. They are less valuable when a team is evaluating a range of options for a specific, real-world task.

Also, resist the urge to reject a tool based solely on the vendor that supplies it. Your personal vendor preferences (or prejudices) may not actually reflect the best interests of the project.

2. I will value flexibility over repetition

Just because it worked last time doesn't mean it's the only way to do it this time. And did it really work as well last time as it could have? Has absolutely nothing changed -- neither the options available, the staff available, nor the expertise of the staff -- that might make an option viable now that wasn't viable earlier? Try to keep an open mind when team members raise new methods that haven't been tried. And even when the decision is made to reject a certain idea for this iteration of a project, don't be too quick to dismiss it if the same idea is proposed the next time.

3. I will weigh all the considerations before arriving at a decision

Be particularly wary of qualitative adjectives, such as "faster," "smaller," "easier," "more scalable," and "more robust" when arguing in favor of tools. Like synthetic benchmarks, they seldom tell the whole story. It may be true that the best-written C++ code will outperform the best-written Java code at the same task. But are the C++ programmers on your team really the best in the business? Does performance outweigh other considerations, such as code maintainability or ease of memory management? For some projects, time to market might be the most important factor; in those cases, the "best" tool for the job might simply be the one that gets it done fastest. Make sure you understand your project's priorities before you argue in favor of any tool.

4. I will recognize the deficiencies of my tools, even ones I prefer

I have yet to see a language, method, or process that is equally good at everything. For example, C might be the only language that makes sense for a project like the Linux kernel, but it's lousy for text processing. Agile methods might work wonders in small groups but fall apart at enterprise-wide scale. Foolish programmers are those who agitate for a specific tool again and again simply because it's the one they understand best; wise programmers are those who are willing to set aside their favorite methods when, deep down, they know they aren't ideally suited to the task at hand.

5. I will not make the perfect the enemy of the good

We've all seen terrible code, and we've all seen the completely wrong tool bent to a task it was never meant to handle. These are the worst-case scenarios. Other times, however, a less-than-optimal solution that achieves the objective is preferable to an ideal solution that's too difficult to implement in the time allotted. It's important that experienced developers raise concerns when they recognize problem areas, but once those issues have been aired, it's time to set the debate aside and focus on the goal. Some fights are better left for another day.

6. I will admit my mistakes, rather than compound them

We're all wrong some of the time. We all put our feet in our mouths some of the time. No matter how experienced you are, no matter how sure you are of your footing, sooner or later you'll probably meet someone who understands a problem or tool better than you do. These moments aren't defeats. They are opportunities. To be a good advocate, you should not only be self-assured enough to argue passionately for your position, but also self-aware enough to recognize a lesson worth learning.

Failing that, you can always go home and bicker on a message board -- and good luck to you.

This article, "My manifesto: Only an idiot would disagree," originally appeared at InfoWorld.com. Read more of Neil McAllister's Fatal Exception blog and follow the latest news in programming at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.