Languages Don’t Matter (Part Deux)
Last week, I wrote about how languages don’t matter; that it’s what you do with them that matters the most. This post generated predictable controversy, and it appears I may have lacked some clarity in my original arguments. I will correct this now.
In my original post I illustrated the creation of chess sets using metal versus stone. I stated that both craftsmen produced things of value and that the consumer never really cared about the specific methods applied in the workshop for the creation of the chess set.
I think to fully understand the analogy and the logic behind it, we need to take a step back.
If you look at the top of this page in the header, you’ll find the vision statement for this blog: “perfect the art of software development”. I chose this as a theme for 2013 and beyond, because I believe this is where I need to go in my own development, and where I believe we all can go as software developers. Nobody is ever perfect as a software developer; one can only hope to continuously perfect their art, their craft.
Software developers tend to think in terms of languages, but this single channel viewpoint removes a critical number of elements from the software development process. User interface, user experience, project planning, feature creation and marketing are all components of the process that most developers either have limited exposure to or outright ignore. But they cannot be ignored in an overall look at software development.
Thus, an argument between software developers over what language to use (akin to an argument between craftsmen over what size hammer to use) unnecessary inflates a small issue into a large one. And it’s detrimental to the development process.
Developers like to think that companies hire developers to write code. But companies do not hire developers to write code; they hire developers to solve problems. They hire developers with the expectation that the developer knows about, or can learn about, the problems of the company, and find a creative solution to those problems at minimal cost.
It is therefore up to the developer to choose what tools they will use to achieve the outcome. The customer doesn’t much care what tools the developer uses; they only care that the outcome they desired is achieved. And thus, is the point of my analogy:
The craftsmen use different tools to achieve similar outcomes. Having an argument between themselves over whose tools are better, and deriding the tools of one another, debases and devalues the work that they perform. Each craftsman prefers his or her tools for a reason. And good craftsmen will debate the merits of various tools, but when that debate becomes the central theme of their profession, the work suffers.
The analogy makes an assumption, one that may or may not be obvious: the craftsmen have selected tools that are appropriate for all aspects of the work they are performing. The tools matter to the work, to be sure; but they are not the work in and of itself. They are only a component of the work to create the thing of value and beauty.
Do languages ultimately matter? Of course they do, but in context: they are a small part of a very large puzzle, and they are secondary to the primary objective of a developer: to solve problems. Religious-like adherence to a particular language, pattern or framework breeds contempt for the others at the expense of the creative process. A good developer should be able to examine a problem, pick an appropriate tool, and implement a solution that satisfies the needs of the project.
So what am I after in making this case? I want developers to recognize and understand that fighting about which language is better or debasing other languages for sport is a foolish endeavor that won’t accomplish anything. I want developers to recognize that language selection is a terribly small component in an overall development process that focuses on solving problems. I want developers to agree that they will solve the problem with the right tool, rather than trying to fit a square peg into a round hole. I want developers to realize that selecting a language is about picking the tool that will solve their current class of problem, but that it may not be suitable for all problems, all the time.
As developers, concepts such as maintainability, extensibility and liability should already be factored into our decision making process. Just as a craftsman who constructs with a particular material understands the limitations of that material, we should already know what the limitations of our tools are. If we fail to understand those limitations before moving forward, we have completely failed in our obligations. But knowing the limitations of a particular tool does not equate to deriding that tool; understanding the reasonable limitations of PHP or Perl or Python does not mean these tools become ineffective.
Developing software is about outcomes, not processes. As developers we often forget that it’s the user that we are working for. The user doesn’t care about our petty squabbles over language selection. To them, languages don’t matter; how we use them to improve their lives is what truly matters.
Learning design patterns doesn't have to suck.
Design patterns open a whole new world of possibilities. So why are you avoiding them? This brand new book will help you finally understand these wonderful programming techiques!Learn design patterns TODAY »