Static vs. Dynamic? Strong vs. Weak? Functional vs. Objective? Duck vs. Strict? Tabs vs. Spaces? vi vs. emacs! Code Review, Code Style, Source Control, Build Systems, Compilers and Stacks; oh, my.

If you read the technology press, particularly those sites targeted towards developers and the myriad blogs produced by developers, you would think that the above questions and areas of concern are the most important things to consider when designing and developing an application. They aren’t.

The choice of tools is not the biggest factor in determining the quality or speed with which your products ship. The more time you spend arguing about them the less time you spend working on the things that will contribute to your Apps success.

A Bad Worker Will Never Find a Good Tool

No other industry invests in the tools the power of success or failure; attributes the qualities of the tools to the thing produced or make such sweeping judgements of people based on their choice of tools. Perhaps this has to do with the ultimate plasticity of the digital medium, and the heady feeling of walking on stilts that you can get from working with a well orchestrated stack of technology: write one small line of code, and watch the system take great strides towards your intended goal.

It’s this sense of great power and precise control that ties people in the technology field so tightly to their tools it ends up branding them: “Java Developer”, “C Coder” and “JavaScript Developer” are commonly used to describe the human resources we’ve all become, and all imply a fairly specific set of skills, traits and prejudices (ActionScript developers in particular). While familiarity with a particular set of tools is important to being a productive programmer, sometimes the tools you know best aren’t the right ones for the job.

To the extent that our jobs define who we are, our choice of tools says something about our particular temperaments and goals. But the critical skills are adaptability and the willingness to learn new technologies in order to deliver Apps which are designed with the User first in mind. Deciding on which tools you want to use for a particular App is putting the cart before the horse, figure out where you want to go and find out the best way to get there then choose the right tools for the task at hand.

Type Systems are S&M for Software Engineers

One of the social environmental hazards of living in San Francisco is occasionally meeting people who are very open about their kinks. Sure, it can make for titillating cocktail hour chatter, but unless it’s an interest you share, the extended details can leave you feeling like you need a shower. It can get sticky quickly and there are some obvious parallels to the endless discussion of type systems in the software engineering world:

“Strong vs. Weak” typing is totally a Top “I need you to do this exactly the way I tell you” vs Bottom “you might have to coerce me first…” approach to the question of, uh, coupling.

“Strict vs. Duck” type systems have advocacy groups arguing as stringently about what qualifies one to use a particular method as others do about who can use a particular bathroom.

It can feel safer to work inside of carefully crafted constraints, with strict rules on what you can and can’t do—if you’re into that sort of thing—but even the best type system doesn’t save you from having to rigorously test your app. Most of the problems you’ll find with the app will be about usability, not the type of crashing bugs that type systems can help prevent, but never completely cure.

Personally, I’d be content with a safe word which would let me escape both discussions. I always liked Guido’s “we’re all adults here, right?” attitude generally, and I appreciate that void* will always be there for me when I need it.

Apps are Delivered on Platforms

Here’s the thing, neither your favorite tool or the one chosen type system will deliver an app. Apps are built by developers, using tools targeting platforms that users purchase devices to run. Multiple tools, with different languages, for different purposes to produce different kinds of output: code, resources, documentation, marketing materials, plans, release check-lists and on and on.

Platforms have native tools for app building, and learning those tools in order to deliver the App you want to your target users is a much smaller problem than figuring out who they are and what they want in the first place, then learning all the other tools you’ll need to manage delivery distribution and marketing of the product of that set of tools.

Great apps are focused intently on their users and are honed over many revisions based on feedback from them. The easiest apps to write are the ones you want for your self. Harder is writing apps which serve a particular purpose, or test some ideas you have in a clean and concise way.

Tools are Just Tools

Take away the Platforms and Tools and the digital scaffold of Source Control, Build Automation and Integrated Development Environments and the only thing left is the App itself, how it meets the needs of it’s users and how to shape the ideas that the developer or team has into a working product.

Focusing obsessively on tools, as a developer, team or industry is worse than wasted time, it misses the point of developing software. Instead of arguing over how we should be agreeing on the what and why of our creative endeavor: build the best apps and systems we can so that people will be delighted by them.