| « A better personal biography | Five Ways To Write Better Code » |
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.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 1/16/2013 at 7:00 am
JonoB wrote at 1/16/2013 8:14 am:
“fighting about which language is better or debasing other languages for sport is a foolish endeavor that won’t accomplish anything.”
Sure it does. It strokes the (tiny) ego of the person debasing another language.
Excellent article.
Kaveh Shahbazian wrote at 1/19/2013 3:56 pm:
I am writing code for almost 23 years (from when I was 14 or 15) and I write good code (based on judgments of my co-workers) and I solve real problems (almost one major one per every 3 week); but above all that I ENJOY CODING! And the day that enjoyments stops then F%CK the customer and all companies and I’ll go work in a library or maybe I open a coffee-shop or join some charity group or something with more meaning or more money – and definitely that would be a far easier money than keeping pile of different logic implemented in different technologies and bear this complicated swarm of logic in your head, day and night to every spot in your life. The only thing that really matters is: I love coding! I love to press a button and watch the characters appear magically on my screen from nowhere and bit by bit become more like the language I love (well almost ;) FYI it’s C# in may case – then comes Go and then F#). Without that “love” there IS NO SOFTWARE (that some crap minded company can enjoy the money that comes out of it).
Another thing: programming languages are not tools; they are the material that we work on them with our tools: our minds. The carpenter loves to touch the wood and shape the wood with it’s tools as we love to shape the code with our minds.
Deleting comments that oppose your points is not a great way to promote your blog! :)
Brandon Savage (@brandonsavage) wrote at 1/20/2013 1:47 pm:
Comments are all moderated to prevent spam. That means if I don’t visit the blog for a day, I don’t approve comments. Your comment was approved as soon as it was seen.
No! Really it was a mistake and that other discussion that I had was about Dapper (IMHO a great tool) and I was awake for ~36 hours! I really meant it when I said that I made a mistake; and I humbly apologize again if I seemed as a troll.
Devon H. O'Dell (@dhobsd) wrote at 1/23/2013 11:23 pm:
In your initial post, you reference my comment to another similar post on why language choice doesn’t matter and discard my points as irrelevant. My overarching point in that comment was exactly the point that you seem to be trying to make here: it’s smart to pick a tool that is fit for the purpose at hand (whether that tool is a language, algorithm, whatever).
So, now I’m confused because you seem to be saying that having a large toolset (of languages) is important, so that you can make intelligent decisions about what language to use. At that point, you have to admit that you are making an argument that languages *do* matter in very much the same way that hammer size matters. Try hammering drywall nails with a sledgehammer. It feels now like the issue is that arguing about language choice is pointless (and it largely is).
At the end of the day, you do what you can with what you know, and I think that most of these arguments are tangential to the real point: never stop learning new things. It lets you do more because you know more.
| « A better personal biography | Five Ways To Write Better Code » |